Over 87,000 MongoDB instances may be vulnerable to trivial, remote memory leaks via a critical vulnerability allocated CVE-2025-14847.
Dubbed “MongoBleed”, the vulnerability (already patched for MongoDB Atlas DBaaS instances), lets a remote and unauthenticated attacker pull credentials, cloud keys or other tokens straight from database memory.
Elastic Security’s Joe Desimone published a public proof-of-concept (POC) on Christmas Day – saying it took him just 10 minutes to generate the exploit, using Cursor and a “single prompt.” It helped that the vulnerability trigger was included as a unit test in the public fix commit, he posted on X.
(As The Stack previously noted, enterprise security teams need to watch repositories, not just CVEs; as soon as a public pull request to fix a security issue lands, LLMs can help anyone potentially weaponise it at pace.)
CVE-2025-14847: Detection logic
Any server with a publicly exposed MongoDB port for MongoDB servers within the affected versions list (3.6.0 – 8.2.2) should patch or mitigate. Ditto private servers that might be reachable via lateral movement. Patches are available for all supported versions from 4.4 through 8.0, MongoDB said.
(Exploitation is trivial, if potentially time-consuming. Crudely, it involves sending a broken BSON message. The server returns an error message helpfully containing a 1MB block of data from the database. Attackers need to do this a LOT of times to get value and this may help detection)
As security practitioner Eric Capuano notes, exploitation (not reported in the wild yet, but likely to happen soon or already be happening) “seems to be only detectable in the MongoDB server logs which are extremely unlikely to be shipped to any SIEM, and it requires somewhat complex logic which could be tricky to port into most SIEM detection engines…”
But the method of exploitation based on the current POC gives a “reliable detection signal: a source IP with hundreds or thousands of connections but zero metadata events is almost certainly not legitimate traffic…”
The tirelesss Florian Roth also has free detection tooling here that correlates three MongoDB log event types. ("No network connectivity, no agents, no SIEM required" and "handles large log files without loading into memory.")
Chris Wallis, founder of attack surface management firm Intruder, commented that for many MongoDB community edition users, “The first port of call here would be to get that service off the internet...
“There’s always going to be new vulns in software, not having stuff exposed to the internet that doesn’t need to be there is step one,” he wrote.
Meanwhile, between 87,000 (Censys) and 200,000+ (Shodan) MongoDB instances are potentially exposed to trivial, automated data breaches.
Several experts have noted that a considerable number of exposed instances may be Ubiquiti UniFi controllers for network switches, VoIP phones, and access points; these use MongoDB in their backend.
Users should update to 8.2.3, 8.0.17, 7.0.28, 6.0.27, 5.0.32, or 4.4.30.
As security firm Wiz notes, those unable to otherwise patch or mitigate can "disable zlib compression by explicitly omitting it from networkMessageCompressors or net.compression.compressors. Safe alternatives include snappy, zstd, or fully disabling compression."
The link has been copied!
