Serious Vulnerability in MongoDB Leaves Cloud Environments Vulnerable

MongoDB has disclosed a high-severity unauthenticated information leak vulnerability, tracked as CVE-2025-14847 and dubbed MongoBleed, affecting multiple supported and legacy MongoDB Server versions. Security firm Wiz warns that the vulnerability is being actively exploited.

CVE-2025-14847 stems from a flaw in MongoDB Server’s zlib-based network message decompression logic, which is processed prior to authentication. By sending malformed, compressed network packets, an unauthenticated attacker can trigger the server to mishandle decompressed message lengths, resulting in uninitialized heap memory being returned to the client. This allows attackers to remotely leak fragments of sensitive in-memory data without valid credentials or user interaction.

Based on Wiz data, 42% of cloud environments have at least one instance of MongoDB in a version vulnerable to CVE-2025-14847, including both publicly exposed and internal resources. Wiz has been able to validate many internet-facing instances as exploitable.

Censys has reported observing 87K potentially vulnerable instances worldwide. A working exploit has been publicly available since December 26, 2025, with initial reporting of exploitation in the wild reported shortly after.

The vulnerability impacts MongoDB in versions 8.2.0 through 8.2.2, 8.0.0 through 8.0.16, 7.0.0 through 7.0.27, 6.0.0 through 6.0.26, 5.0.0 through 5.0.31, 4.4.0 through 4.4.29, and all MongoDB Server v4.2, v4.0, and v3.6 versions.

The vulnerability also impacts several Linux distribution packages such as rsync, with varying severity and unknown exploitability as of this time.

Wiz advises security teams to take the following steps:

Upgrade immediately to one of the patched versions: 8.2.3, 8.0.17, 7.0.28, 6.0.27, 5.0.32, or 4.4.30.

If immediate patching is not possible, disable zlib compression by explicitly omitting it from networkMessageCompressors or net.compression.compressors. Safe alternatives include snappy, zstd, or fully disabling compression.

Restrict network exposure of MongoDB servers (e.g., firewall rules, private networking).

Monitor MongoDB logs for anomalous pre-authentication connections or unexpected crashes (see this blogpost from Eric Capuano for additional detection guidance, and this detection tool from Florian Roth).

Plan upgrades for any remaining end-of-life MongoDB versions, as they remain permanently vulnerable.

More information about the vulnerability can 
be found here.

Leave a Reply

Your email address will not be published. Required fields are marked *