MongoBleed (CVE-2025-14847) 2025: How a zlib Bug Let Anyone Read Secrets From MongoDB Server Memory

MongoBleed, tracked as CVE-2025-14847, is a memory disclosure flaw in MongoDB Server's zlib network compression that MongoDB published on 19 December 2025. By sending a malformed compressed message, an attacker with nothing more than network access to the database port could make the server return fragments of uninitialised heap memory, before any login took place. That memory can hold database passwords, API and cloud keys, session tokens and other data, according to researchers. A public exploit appeared over Christmas, Wiz reported exploitation in the wild soon after, and CISA added the flaw to its Known Exploited Vulnerabilities catalogue on 29 December 2025. Censys counted more than 87,000 potentially vulnerable instances on the internet. The identity lesson is simple: a patch stops future leaks, but any secret that passed through an exposed server's memory has to be treated as possibly stolen.

At a glance

What happened

MongoDB clients and servers can compress the messages they exchange over the wire protocol, and zlib is one of the supported compressors. According to Akamai, a compressed message carries an uncompressedSize field inside an OP_COMPRESSED structure. An attacker can set that field to a value larger than the real payload. The server then allocates a buffer of the claimed size, most of which contains uninitialised heap data left over from earlier work.

Wiz describes the root cause as "incorrect length handling in message_compressor_zlib.cpp": the code returned the size of the allocated buffer rather than the length of the data that was actually decompressed. The server therefore treats the leftover memory as part of the message. When it then fails to parse the malformed BSON document, Akamai says the server "returns an error response that includes the original message and the leaked heap contents". Repeating the request pulls out different fragments of memory each time.

The critical detail is timing. Wiz researchers said the decompression logic "is processed prior to authentication". No username, password or certificate is needed. Wiz's Merav Bar and Amitai Cohen noted, as quoted by The Hacker News, that "Internet-exposed MongoDB servers are particularly at risk". Security researcher Kevin Beaumont told BleepingComputer that an attacker needs only "an IP address of a MongoDB instance to start ferreting out in memory things such as database passwords".

MongoDB's chief technology officer, Jim Scharf, published a timeline on 29 December 2025. It says the MongoDB Security Engineering team discovered the issue at 19:00 on 12 December, validated and built a fix over the next two days, began patching the Atlas managed service fleet between 15 and 17 December, and had the rest of Atlas patched on 18 December. The CVE was published on 19 December and a community forum post with patch details followed, dated 23 December in MongoDB's timeline. That forum post said MongoDB had "no evidence that this issue has been exploited or that any customer data has been compromised" at that point. Fixed releases are 8.2.3, 8.0.17, 7.0.28, 6.0.27, 5.0.32 and 4.4.30. Scharf stressed that the flaw "is not a breach or compromise of MongoDB, MongoDB Atlas (our managed MongoDB Server offering), or our systems."

The situation changed over the Christmas holiday. BleepingComputer reported that Joe Desimone, a security researcher at Elastic, published proof-of-concept code, and Wiz says "A working exploit has been publicly available since December 26, 2025". On 27 December Censys published an advisory counting more than 87,000 potentially vulnerable instances. Wiz then reported on 28 December that it had observed MongoBleed "exploitation in the wild", and CISA added CVE-2025-14847 to the KEV catalogue on 29 December with a remediation deadline of 19 January 2026 for US federal civilian agencies, according to The Hacker News.

Researchers were candid about what they did not know. Ben Read of Wiz told CyberScoop: "We have observed exploitation attempts and evidence of active exploitation", but the activity could not be attributed to a particular group. VulnCheck's Caitlin Condon said "Real-world attack details have been oddly lacking so far." BleepingComputer noted unverified claims online linking MongoBleed to an attack on the game Rainbow Six Siege; no source we opened confirmed that link.

Timeline

How it happened: the identity attack path

1. Find a reachable server. The attacker needs only network access to a MongoDB instance, which internet scanning services such as Censys and Shadowserver showed was available for tens of thousands of servers.
2. Skip authentication entirely. A compressed message with an inflated uncompressedSize is handled by the zlib decompression code before the server asks who the client is, so database users, passwords and certificates never come into play.
3. Read leftover memory. The server allocates a larger buffer than the real data, fails to parse the malformed document and returns an error that includes uninitialised heap contents.
4. Repeat and harvest. Each request can return different fragments. Attackers can collect them and search for credentials, API and cloud keys, session tokens and configuration details, the categories BleepingComputer lists as at risk.
5. Reuse what leaks. A database password or cloud key found in memory is a working non-human identity. It can be used later from anywhere, long after the vulnerable server has been patched.
6. Leave little behind. Ben Read of Wiz told CyberScoop that because it is a memory leak, "there isn't malware left on the disk, or any durable forensic evidence that data was accessed."

Impact

• Exposure: Censys reported more than 87,000 potentially vulnerable instances. BleepingComputer, citing Censys data from 27 December, said about 20,000 were in the United States, about 17,000 in China and fewer than 8,000 in Germany. Shadowserver counted almost 75,000 unpatched instances out of about 79,000 publicly exposed, according to CyberScoop.
• Cloud estates: Wiz found that "42% of cloud environments have at least one instance of MongoDB in a version vulnerable to CVE-2025-14847", which includes instances not reachable from the internet.
• Managed service: Wiz says Atlas instances were "upgraded automatically and no customer action is required", and MongoDB says it patched hundreds of thousands of Atlas instances within days.
• Confirmed victims: none named publicly in the sources we reviewed. The 87,000 figure is a count of exposed and potentially vulnerable servers, not of servers from which secrets were stolen.

What this means for NHI governance

MongoBleed did not target a person. It targeted a server that sits at the centre of many applications and holds, in memory, the material that machines use to prove who they are. Database user passwords, connection credentials, keys and session tokens are all non-human identities, and any of them could end up in a leaked fragment. Unlike a login attempt, the leak does not produce an authentication event, so the usual identity controls, MFA, lockouts and failed login alerts, never see it.

This is the same pattern as CitrixBleed: a memory disclosure bug turns valid credentials and tokens into loot, and those credentials keep working after the patch is applied. It also echoes the Gravity SMTP API key exposure, where unauthenticated requests pulled live service credentials from web servers. In each case, patching closes the hole but does not revoke anything that has already leaked.

The governance question is therefore not only "are we patched?" but "which secrets could this server have held, who owns them, and how quickly can we rotate them?" Organisations that know which applications and service accounts connect to each database, and that use short-lived or automatically rotated credentials, can answer that in hours. Those that rely on long-lived passwords in configuration files often cannot. Wiz's point that 42% of cloud environments had a vulnerable instance also shows that internal databases matter: an attacker already inside a network can reach servers that internet scans never see.

Recommendations

• Patch or disable zlib. Upgrade to 8.2.3, 8.0.17, 7.0.28, 6.0.27, 5.0.32, 4.4.30 or later. Where that is not possible, Wiz advises removing zlib from networkMessageCompressors or using snappy or zstd instead.
• Take databases off the internet. Block inbound access to TCP 27017 from untrusted networks, as Akamai recommends, and allow connections only from the application hosts that need them.
• Assume exposure and rotate. For any server that was reachable while unpatched, rotate MongoDB user passwords, application connection credentials and any keys or tokens the server handled. The Secrets Management Guide covers central storage and rotation, and Challenges of Rotating NHIs explains why it is hard to do quickly.
• Map who connects to each database. Keep an inventory of the service accounts and applications that use each MongoDB deployment, with a named owner for each, following the Service Account Security Guide.
• Prefer short-lived credentials. Where possible, issue database credentials dynamically or rotate them automatically, so that a leaked value expires on its own.
• Watch how leaked credentials are used. Since the leak itself leaves little trace, monitor for database logins, key use and token use from unexpected sources after the disclosure window.

Frequently asked questions

What is MongoBleed (CVE-2025-14847)?

MongoBleed is a flaw in MongoDB Server's zlib network compression, published on 19 December 2025. A malformed compressed message makes the server return uninitialised heap memory to the client, and it works without authentication.

Was MongoBleed exploited in the wild?

Yes. Wiz reported exploitation shortly after a public proof of concept appeared around 26 December 2025, and CISA added the flaw to its Known Exploited Vulnerabilities catalogue on 29 December 2025. No specific victim has been publicly confirmed in the sources we reviewed.

Were 87,000 MongoDB servers breached?

No. Censys counted more than 87,000 internet-facing instances that were potentially vulnerable. That is a measure of exposure, not of servers from which data was confirmed stolen. MongoDB Atlas was patched before disclosure.

Related NHI Mgmt Group resources

CitrixBleed 2023 · Gravity SMTP CVE-2026-4020 · Gladinet hardcoded keys exploitation · The secret sprawl challenge · NHI breaches

How NHI Mgmt Group can help

MongoBleed shows that a single unauthenticated bug can expose the database passwords, keys and tokens that applications depend on, and that rotating them quickly is what limits the damage. Our NHI Foundation Level Training Course helps teams inventory, own and rotate these non-human identities before the next disclosure.

References

• MongoDB: MongoDB Server Security Update, December 2025 (29 December 2025)
• MongoDB Community Hub: Important MongoDB patch available (23 December 2025)
• Wiz: MongoBleed (CVE-2025-14847) exploited in the wild (28 December 2025, updated 31 December 2025)
• Censys: MongoBleed, Critical MongoDB Uninitialized Memory Disclosure Vulnerability (CVE-2025-14847) (27 December 2025, updated 18 February 2026)
• Akamai: CVE-2025-14847, All You Need to Know About MongoBleed (30 December 2025)
• BleepingComputer: Exploited MongoBleed flaw leaks MongoDB secrets, 87K servers exposed (28 December 2025)
• CyberScoop: MongoBleed defect swirls, stamping out hope of year-end respite (29 December 2025)
• The Hacker News: MongoDB Vulnerability CVE-2025-14847 Under Active Exploitation Worldwide (29 December 2025)