MongoBleed: 87,000 MongoDB Servers Leaking Memory Like Heartbleed
Want to learn ethical hacking? I built a complete course. Have a look!
Learn penetration testing, web exploitation, network security, and the hacker mindset:
→ Master ethical hacking hands-on
(The link supports me directly as your instructor!)
Hacking is not a hobby but a way of life!
You trust your database to keep your data safe. MongoDB just proved it doesn’t. 87,000 servers are leaking memory to anyone who asks. 😏
December 2025. CVE-2025-14847, rated CVSS 8.7, nicknamed “MongoBleed” because it works exactly like Heartbleed did eleven years ago.
Zlib compression is enabled by default in MongoDB. When a compressed message arrives, the server reads a header claiming how large the data will be after decompression. MongoDB allocates that amount of memory, decompresses the payload, and sends back the response.
The code returned the full buffer size instead of the actual data length. Send a packet claiming to be 1000 bytes when it’s really 100, and MongoDB sends back all 1000 bytes. The extra 900 bytes contain whatever was in memory from previous operations.
What leaks: → Cleartext passwords and credentials → Session tokens and API keys → Customer data and PII → Database configs and system info → Docker paths and client IP addresses
The attack happens before authentication. No login needed. If an attacker can reach port 27017, they can start extracting memory immediately.
Researchers tested the public exploit and pulled over 8,700 bytes of data in 42 fragments from a single scan. A proof-of-concept is already on GitHub. According to Wiz, 42% of cloud environments have at least one vulnerable instance, and exploitation is already happening in the wild.
How to detect an attack: When a MongoDB driver connects, it always sends metadata to identify itself. The driver name, version, operating system. The MongoBleed exploit skips this completely. It connects, grabs memory, and disconnects without ever saying what it is.
The difference is obvious in the logs. Normal traffic runs at 1-3 connections per minute with 99-100% sending metadata. During testing, the exploit generated 111,000+ connections per minute with 0% metadata. If you see an IP making thousands of connections without identifying itself, that’s your red flag.
Using MongoDB Atlas? Your clusters auto-upgrade, so you should be protected. Check that the upgrade already happened.
The fix was one line of code. Changing “return {output.length()};” to “return length;”. One line, sitting wrong in every MongoDB version since 3.6.
Affected versions: → MongoDB 3.6.x, 4.0.x, 4.2.x (all versions) → MongoDB 4.4.0 through 4.4.29 → MongoDB 5.0.0 through 5.0.31 → MongoDB 6.0.0 through 6.0.26 → MongoDB 7.0.0 through 7.0.27 → MongoDB 8.0.0 through 8.0.16 → MongoDB 8.2.0 through 8.2.2
Check if you’re running a vulnerable version: → Run “mongod –version” → Anything between 3.6 and 8.2.2 needs updating
Fixed versions: 8.2.3, 8.0.17, 7.0.28, 6.0.27, 5.0.32, 4.4.30
Can’t patch immediately? Disable zlib compression by setting networkMessageCompressors to exclude zlib. Use snappy or zstd instead. But patch as soon as possible.
Heartbleed taught this lesson in 2014. Eleven years later, 87,000 servers are still making the same mistake.
Want to learn how attackers find and exploit vulnerable systems? I cover reconnaissance, penetration testing, and real-world exploitation techniques in my ethical hacking course:
→ https://www.udemy.com/course/ethical-hacking-complete-course-zero-to-expert/?couponCode=JANUARY26 (The link supports me directly as your instructor!)
Hacking is not a hobby but a way of life. 🎯
#ethicalhacking #mongodb #mongobleed #cybersecurity #infosec #vulnerability #databasesecurity #CVE202514847 #heartbleed #hackingpassion
Research & writing: Jolanda de Koff | HackingPassion.com Sharing is fine. Copying without credit is not.