A severe vulnerability affecting multiple MongoDB versions, dubbed MongoBleed (CVE-2025-14847), is being actively exploited in the wild, with over 80,000 potentially vulnerable servers exposed on the public web.

A public exploit and accompanying technical details are available, showing how attackers can trigger the flaw to remotely extract secrets, credentials, and other sensitive data from an exposed MongoDB server.

The vulnerability was assigned a severity score of 8.7 and has been handled as a “critical fix,” with a patch available for self-hosting instances since December 19.

Exploit leaks secrets

The MongoBleed vulnerability stems from how the MongoDB Server handles network packets processed by the zlib library for lossless data compression.

Researchers at Ox Security explain that the issue is caused by MongoDB returning the amount of allocated memory when processing network messages instead of the length of the decompressed data.

A threat actor could send a malformed message claiming a larger size when decompressed, causing the server to allocate a larger memory buffer and leak to the client in-memory data with sensitive information.

The type of secrets leaked this way could range from credentials, API and/or cloud keys, session tokens, personally identifiable info (PII), internal logs, configurations, paths, and client-related data.

Because the decompression of network messages occurs before the authentication stage, an attacker exploiting MongoBleed does not need valid credentials.

The public exploit, released as a proof-of-concept (PoC) dubbed “MongoBleed” by Elastic security researcher Joe Desimone, is specifically created to leak sensitive memory data.

Security researcher Kevin Beaumont says that the PoC exploit code is valid and that it requires only “an IP address of a MongoDB instance to start ferreting out in memory things such as database passwords (which are plain text), AWS secret keys etc.”

According to the Censys platform for discovering internet-connected devices, as of December 27, there were more than 87,000 potentially vulnerable MongoDB instances exposed on the public internet.

Almost 20,000 MongoDB servers were observed in the United States, followed by China with almost 17,000, and Germany with a little under 8,000.

Exploitation and detection

The impact across the cloud environment also appears to be significant, as telemetry data from cloud security platform Wiz showed that 42% of the visible systems “have at least one instance of MongoDB in a version vulnerable to CVE-2025-14847.”

Wiz researchers note that the instances they observed included both internal resources and publicly exposed ones. The company says that it observed MongoBleed (CVE-2025-14847) exploitation in the wild, and recommends organizations prioritize patching.

While unverified, some threat actors are claiming to have used the MongoBleed flaw in a recent of breach of Ubisoft’s Ranbow Six Siege online platform. 

Recon InfoSec co-founder Eric Capuano warns that patching is only part of the response to the MongoBleed problem and advises organizations to also check for signs of compromise.

In a blog post yesterday, the researcher explains a detection method that includes looking for “a source IP with hundreds or thousands of connections but zero metadata events.”

However, Capuano warns that the detection is based on the currently available proof-of-concept exploit code and that an attacker could modify it to include fake client metadata or reduce exploitation speed.

Florian Roth – the creator of the THOR APT Scanner and thousands of YARA rules- utilized Capuano’s research to create the MongoBleed Detector – a tool that parses MongoDB logs and identifies potential exploitation of the CVE-2025-14847 vulnerability.

Safe lossless compression tools

MongoDB addressed the MongoBleed vulnerability ten days ago, with a strong recommendation for administrators to upgrade to a safe release (8.2.3, 8.0.17, 7.0.28, 6.0.27, 5.0.32, or 4.4.30).

The vendor is warning that a large list of MongoDB versions are impacted by MongoBleed (CVE-2025-14847), some legacy versions released as early as late 2017, and some as recent as November 2025:

• MongoDB 8.2.0 through 8.2.3
• MongoDB 8.0.0 through 8.0.16
• MongoDB 7.0.0 through 7.0.26
• MongoDB 6.0.0 through 6.0.26
• MongoDB 5.0.0 through 5.0.31
• MongoDB 4.4.0 through 4.4.29
• All MongoDB Server v4.2 versions
• All MongoDB Server v4.0 versions
• All MongoDB Server v3.6 versions

Customers of MongoDB Atlas, the fully managed, multi-cloud database service, received the patch automatically and don’t need to take any action.

MongoDB says that there is no workaround for the vulnerability. If moving to a new version is not possible, the vendor recommends that customers disable zlib compression on the server and provides instructions on how to do so.

Safe alternatives for lossless data compression include Zstandard (zstd) and Snappy (formerly Zippy), maintained by Meta and Google, respectively.