MongoBleed Exploit: The MongoDB Memory Leak Hitting 87,000 Servers

Updated December 29, 2025: Added Shodan patch adoption data and detection tool guidance.

Attackers are actively exploiting MongoBleed to extract credentials from MongoDB servers without authentication. The vulnerability has already been linked to a major gaming breach that forced Ubisoft to take Rainbow Six Siege offline.

The Ubisoft incident is unlikely to be the last. Internal MongoDB instances, often holding more sensitive data than internet-facing systems, are equally vulnerable. Organisations with network access controls but no patch may discover they were compromised only after credentials extracted via MongoBleed surface in later attacks. Expect more breaches to emerge in the coming weeks as forensic investigations catch up.

CVE-2025-14847, now dubbed "MongoBleed" after the infamous Heartbleed bug, affects every MongoDB version released since 2017. Wiz researchers have confirmed exploitation in the wild, and Censys data shows 87,000 vulnerable instances exposed on the public internet. 42% of cloud environments have at least one affected MongoDB instance (Wiz, 2025).

This is not a theoretical risk. Working exploit code went public on December 26. By December 27, attackers had already used it to breach Ubisoft's infrastructure.

Get threat intelligence like this delivered to your inbox. Subscribe to CyberDesserts for practical security insights, no fluff.

What is MongoBleed?

MongoBleed exploits a flaw in how MongoDB handles zlib-compressed network messages. The bug sits in the decompression logic, specifically in message_compressor_zlib.cpp, where the server returns the allocated buffer size instead of the actual decompressed data length.

When an attacker sends a malformed compressed packet claiming an inflated size, MongoDB allocates a large buffer but only fills part of it with actual data. The server then treats the entire buffer as valid, causing BSON parsing to read whatever happens to be in adjacent heap memory until it hits a null byte.

The result: chunks of server memory leak back to the attacker. No authentication required.

MongoDB's advisory was blunt: "We strongly suggest you upgrade immediately."

Why MongoBleed is Dangerous

Three factors make this vulnerability exceptionally severe.

Pre-authentication exploitation. The decompression happens before any login check. An attacker only needs network access to port 27017. This is exactly the exposure that continuous threat exposure management (CTEM) programs are designed to catch before attackers do.

Trivial exploitation. Joe Desimone, a security researcher at Elastic Security, published a working exploit on Christmas Day. He noted it took him just 10 minutes to create using an AI coding assistant and a single prompt. The vulnerability trigger was included as a unit test in the public fix commit, making weaponisation straightforward for anyone monitoring the repository.

Kevin Beaumont, an independent security researcher known for his DoublePulsar blog, validated the exploit and demonstrated it extracting AWS secret keys and plaintext database passwords from a test instance. His early warning on December 25 helped kick off the security community's rapid response.

Massive attack surface. Censys identified 87,000 potentially vulnerable MongoDB instances exposed to the internet as of December 27. The United States leads with nearly 20,000 exposed servers, followed by China with 17,000 and Germany with 8,000. Wiz data shows 42% of cloud environments contain at least one vulnerable MongoDB instance.

Patched versions are not yet visible in exposure data. Shodan scans of port 27017 queried on December 29 show all ten of the most common MongoDB versions are vulnerable. None of the patched releases (8.0.17, 7.0.28, 6.0.27, 5.0.32, 4.4.30) appear in the top 10.

Shodan data can lag by days to weeks depending on when each host was last scanned. Patches were released December 19, but MongoDB's public announcement came December 24, giving most organisations less than a week to respond.

Source: Shodan, December 29, 2025. Query: product:"MongoDB"

The Rainbow Six Siege Breach

MongoBleed is not a theoretical threat. Within 24 hours of the public exploit release, attackers reportedly used it to breach Ubisoft's infrastructure.

On December 27, Rainbow Six Siege players worldwide logged in to find approximately $13 million worth of in-game currency deposited in their accounts. Attackers had gained access to backend systems, allowing them to grant 2 billion R6 Credits to player accounts, unlock every cosmetic item including developer-only skins, hijack the in-game ban ticker to mock Ubisoft, and issue random bans and unbans to players and streamers.

Ubisoft was forced to take the game servers completely offline while rolling back all transactions. Multiple threat groups claimed involvement, with at least one alleging they used MongoBleed to pivot from an exposed MongoDB instance into internal Git repositories containing decades of source code.

Ubisoft has not confirmed the exact attack vector, but the timing aligns precisely with MongoBleed's public disclosure.

Stay ahead of the next one. Subscribe to CyberDesserts for
vulnerability alerts and practical security guidance.
Join free →

What MongoBleed Leaks

The exploit returns fragments of heap memory that can contain recent database queries and their results, cached authentication credentials, API keys and cloud secrets (AWS, Azure, GCP), session tokens and connection UUIDs, application configuration data, internal server state and paths, and data from other connections sharing the same memory space.

Desimone's exploit systematically probes memory regions by crafting malformed BSON documents with varying length fields. Each probe at a different offset can leak different memory regions. In demonstrations, the tool extracted over 8,700 bytes across 42 fragments, including system metrics, network statistics, and Docker container paths.

Affected MongoDB Versions

Nearly every MongoDB release from the past seven years is vulnerable:

• MongoDB 8.2.0 through 8.2.2
• MongoDB 8.0.0 through 8.0.16
• MongoDB 7.0.0 through 7.0.27
• 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, v4.0, and v3.6 versions

Versions 4.2, 4.0, and 3.6 are end-of-life with no patches available. If you run these, you must upgrade to a supported version.

Note: The same CVE also affects certain Linux distribution packages of rsync that use zlib, though exploitation of rsync has not been confirmed.

Patched Versions and Downloads

MongoDB released patches on December 19, 2025. Upgrade to:

• 8.2.3 or later
• 8.0.17 or later
• 7.0.28 or later
• 6.0.27 or later
• 5.0.32 or later
• 4.4.30 or later

Download patched versions from:

• Community Edition: mongodb.com/try/download/community
• Enterprise Edition: mongodb.com/try/download/enterprise

For containerised deployments, pull the latest official images from Docker Hub and redeploy.

Is MongoDB Atlas Affected?

No. MongoDB patched all Atlas deployments before public disclosure on December 24. If you use Atlas exclusively, no action is required.

MongoBleed only affects self-hosted MongoDB installations, whether on-premises, in your own cloud infrastructure, or in containers you manage.

How to Detect MongoBleed Exploitation

The security community responded rapidly with free detection tools. If your MongoDB was exposed before patching, assume you were scanned and check your logs.

The Detection Signal

Eric Capuano, co-founder of Recon InfoSec, identified the key behavioural signature. Every legitimate MongoDB driver, whether PyMongo, the Node.js driver, mongosh, or any other, sends client metadata immediately after connecting. The MongoBleed exploit connects, extracts memory, and disconnects without ever sending metadata.

A source IP with hundreds or thousands of connections but zero metadata events is almost certainly exploitation, not legitimate traffic.

MongoBleed Detector by Florian Roth

Florian Roth, creator of the THOR APT Scanner and thousands of YARA rules, built on Capuano's research to create a standalone detection tool. The shell script analyses MongoDB JSON logs for the characteristic attack pattern without requiring network connectivity, agents, or a SIEM.

Download: github.com/Neo23x0/mongobleed-detector

Velociraptor Artifact by Eric Capuano

For teams using Velociraptor for incident response, Capuano published a detection artifact that parses MongoDB logs and identifies exploitation patterns. This is currently one of the only defensive signatures available for CVE-2025-14847.

Read the full detection methodology: Hunting MongoBleed

Detection Caveats

The current exploit creates a distinctive signature: extreme connection velocity (100,000+ per minute) with zero client metadata. However, a motivated attacker could modify the exploit to send fake metadata, trading speed for stealth. Do not rely solely on behavioural detection. Patch first.

How to Check Your MongoDB Version

Connect to your MongoDB instance and run:

db.version()

Or from the command line:

mongod --version

Compare the output against the affected versions list. Any version prior to the December 19 patches is vulnerable.

For containerised deployments, check the image tag. Common images like mongo:latest may or may not include the patch depending on when you last pulled.

Immediate Mitigation: Disable Zlib Compression

If you cannot patch immediately, disable zlib compression as a temporary workaround.

Start mongod or mongos with compression explicitly excluding zlib:

mongod --setParameter networkMessageCompressors=snappy,zstd

Or in your configuration file:

net:
  compression:
    compressors: snappy,zstd

Valid alternatives to zlib include snappy and zstd. You can also disable compression entirely with compressors: disabled.

This removes the attack vector but is not a substitute for patching.

What to Do Now

1. Assume compromise if you were exposed. If your MongoDB was internet-accessible before the patch, treat it as potentially exploited. Run the MongoBleed Detector against your logs. Rotate any credentials that may have been in memory.

2. Patch immediately. Apply the December 19 patches to all self-hosted MongoDB instances across production, staging, development, and CI/CD environments.

3. Verify network exposure. MongoDB should never be directly accessible from the internet. Use firewalls, VPNs, or private networks to restrict access to port 27017.

4. Enable authentication if missing. Older MongoDB versions shipped with authentication disabled by default. Authentication would not have prevented MongoBleed, but it reduces your overall attack surface.

5. Check for end-of-life versions. Versions 4.2, 4.0, and 3.6 have no patches. You must upgrade.

6. Review cloud deployments. If you use MongoDB in containers or Kubernetes, verify that your images are updated. Self-managed cloud deployments are not automatically patched like Atlas.

Before You Go

This vulnerability highlights why continuous exposure management
matters. If you're patching reactively, you're always behind.

Related: NIST-Aligned CTEM: Moving Beyond Point-in-Time Scanning

Frequently Asked Questions

Can attackers steal my entire database with MongoBleed?

No. MongoBleed leaks fragments of heap memory, not structured database contents. Attackers get random chunks of whatever was recently in server RAM. This can include credentials and secrets, but is not equivalent to a full database dump.

Can attackers use MongoBleed for remote code execution?

No. Some early reports incorrectly described this as an RCE vulnerability. MongoBleed enables information disclosure only. However, leaked credentials or keys could enable follow-on attacks that do result in code execution.

Is MongoBleed being actively exploited?

Yes. Wiz has confirmed exploitation in the wild. The Ubisoft breach is strongly suspected to have involved MongoBleed based on timing and threat actor claims, though Ubisoft has not officially confirmed the attack vector.

Does authentication protect against MongoBleed?

No. The vulnerability is exploited during message decompression, which occurs before authentication. An attacker only needs network access.

What if I am running MongoDB in Docker?

Check your image version. Official MongoDB images have been updated, but you need to pull the latest version and redeploy. Images tagged with specific vulnerable versions remain exploitable.

Is rsync also vulnerable?

CVE-2025-14847 has been assigned to a related issue in rsync packages that use zlib. However, exploitation of rsync has not been confirmed as of this writing.

Why is it called MongoBleed?

Joe Desimone named it after Heartbleed, the 2014 OpenSSL vulnerability that also leaked server memory through a similar length-handling bug. Both vulnerabilities allow attackers to "bleed" sensitive data from memory without authentication.

The Bigger Picture

MongoBleed exposes a persistent problem: MongoDB's developer-friendly defaults made it popular, but also made misconfiguration common. For years, security researchers have found internet-exposed databases lacking authentication, leaking healthcare records, financial data, and personal information.

Until now, many of these exposed instances relied on obscurity. No known remote exploit existed that worked without credentials. MongoBleed changes that equation. Every exposed MongoDB instance is now a target for automated credential harvesting.

The patch takes minutes to apply. The harder question is why these databases were reachable from the internet in the first place. If this incident prompted you to audit your MongoDB security posture, that is the more valuable outcome. The same discipline applies across your stack, from npm package vulnerabilities to misconfigured cloud storage.

Summary

MongoBleed (CVE-2025-14847) is a pre-authentication memory disclosure vulnerability affecting nearly every MongoDB version since 2017. Attackers are actively exploiting it to extract credentials and secrets from server memory.

The Ubisoft breach demonstrates this is not a theoretical risk. 87,000 MongoDB instances remain exposed on the internet. 42% of cloud environments have at least one vulnerable instance.

Patch immediately. Run the detection tools against your logs. Rotate credentials if you were exposed. And verify your MongoDB instances are not reachable from the public internet.

Last updated: December 29, 2025

References and Sources

1. MongoDB, Inc. (2025). CVE-2025-14847 Security Advisory. SERVER-115508. Zlib compressed protocol header length confusion may allow memory read.
2. Wiz Research. (2025). MongoBleed (CVE-2025-14847) exploited in the wild. December 28, 2025.
3. Censys. (2025). MongoDB instance exposure data. 87,000 potentially vulnerable instances identified.
4. Joe Desimone. (2025). mongobleed PoC. Elastic Security. GitHub: joe-desimone/mongobleed.
5. Kevin Beaumont. (2025). MongoBleed vulnerability disclosure and validation. Cyberplace.social, December 25, 2025.
6. Eric Capuano. (2025). Hunting MongoBleed (CVE-2025-14847). Recon InfoSec. Detection methodology and Velociraptor artifact.
7. Florian Roth. (2025). MongoBleed Detector. GitHub: Neo23x0/mongobleed-detector.
8. BleepingComputer. (2025). Exploited MongoBleed flaw leaks MongoDB secrets, 87K servers exposed. December 29, 2025.
9. BleepingComputer. (2025). Massive Rainbow Six Siege breach gives players billions of credits. December 28, 2025.
10. Shodan. (2025). MongoDB version distribution. Query: product:"MongoDB". Retrieved December 29, 2025.