Spent few days analysing MongoDB, please summarize the analysis and findings.

MongoBleed, tracked as CVE-2025-14847, an unauthenticated memory disclosure vulnerability affecting MongoDB across multiple major versions. It allows remote clients to extract uninitialized heap memory from the MongoDB process using nothing more than valid compressed wire-protocol messages.

This is not native RCE. This is not an issue on the library zlib, is more on the compression-decompression and It is a memory leak. It does not leave a lot of traces, It is silent, repeatable, and reachable before authentication.

TL;DR for engineering teams

• What broke MongoDB’s zlib decompression path trusts attacker-controlled length metadata.
• Impact Unauthenticated heap memory disclosure.
• What leaks Raw process memory fragments including credentials, tokens, config strings, runtime metadata, and recently processed data.
• Auth required None.
• Noise level Low. No crashes. No malformed packets. Minimal logs.
• Exposure 213,490 publicly reachable MongoDB instances observed via Shodan on 29 Dec 2025.
• Fix Upgrade immediately or disable zlib compression.
• Reality check Public PoC exists. Scanning is trivial. Exploitation effort is low (links below on the exploit lab, explaination and scanners if you want to find yours

Links

- Full Detailed Blog: https://phoenix.security/mongobleed-vulnerability-cve-2025-14847/

- Exploit explanation and lab: https://youtu.be/EZ4euRyDI8I

- Exploit Description (llm generated from article): https://youtu.be/lxfNSICAaSc
- Github Exploit for Mongobleed: https://github.com/Security-Phoenix-demo/mongobleed-exploit-CVE-2025-14847/tree/main
- Github Scanner for web: https://github.com/Security-Phoenix-demo/mongobleed-exploit-CVE-2025-14847/tree/main/scanner
- Github Scanner for Code: https://github.com/Security-Phoenix-demo/mongobleed-exploit-CVE-2025-14847/tree/main/code-sca

(Note I spend more time writing exploits, have dyslexia, and I'm not a native English, an LLM proofreads some sections, if this offends you, stop reading)

Affected versions

MongoDB Server	Vulnerable versions	Fixed versions
8.2.x	8.2.0 – 8.2.2	8.2.3
8.0.x	8.0.0 – 8.0.16	8.0.17
7.0.x	7.0.0 – 7.0.27	7.0.28
6.0.x	6.0.0 – 6.0.26	6.0.27
5.0.x	5.0.0 – 5.0.31	5.0.32
4.4.x	4.4.0 – 4.4.29	4.4.30
4.2.x	All	EOL
4.0.x	All	EOL
3.6.x	All	EOL

SAAS version of MongoDB is already patched

Technical anatomy

MongoDB supports network-level message compression.

When a client negotiates compression, each compressed message includes an uncompressedSize field.

The vulnerable flow looks like this:

1. Client sends a syntactically valid compressed MongoDB wire-protocol message
2. Message declares an inflated uncompressedSize
3. MongoDB allocates a heap buffer of that declared size
4. zlib inflates only the real payload into the start of the buffer
5. The remaining buffer space stays uninitialized
6. MongoDB treats the entire buffer as valid BSON
7. BSON parsing walks past real data into leftover heap memory

Memory gets leaked out, not a lot of IOC to detect

Root cause (code-level)

The vulnerability originates in MongoDB’s zlib message decompression logic:

src/mongo/transport/message_compressor_zlib.cpp

In the vulnerable implementation, the decompression routine returned:

return {output.length()}; 

output.length() represents the allocated buffer size, not the number of bytes actually written by ::uncompress().

If the attacker declares a larger uncompressedSize than the real decompressed payload, MongoDB propagates the allocated size forward. Downstream BSON parsing logic consumes memory beyond the true decompression boundary.

The fix replaces this with:

return length; 

length is the actual number of bytes written by the decompressor.

Additional regression tests were added in message_compressor_manager_test.cpp to explicitly reject undersized decompression results with ErrorCodes::BadValue.

This closes the disclosure path.

Why is this reachable pre-auth

Compression negotiation occurs before authentication.

The exploit does not require:

• malformed compression streams
• memory corruption primitives
• race conditions
• timing dependencies

It relies on:

• attacker-controlled metadata
• valid compression
• Incorrect length propagation

Any network client can trigger it, hence is super easy to deploy

Exploitation reality

A working proof of concept exists and is public, more details:

• Original PoC by Joe Desimone https://github.com/joe-desimone/mongobleed/
• Technical analysis and reproduction details https://doublepulsar.com/merry-christmas-day-have-a-mongodb-security-incident-9537f54289eb
• Github Exploit for Mongobleed: https://github.com/Security-Phoenix-demo/mongobleed-exploit-CVE-2025-14847/tree/main
• Github Scanner for web: https://github.com/Security-Phoenix-demo/mongobleed-exploit-CVE-2025-14847/tree/main/scanner
• Scanner for Code: https://github.com/Security-Phoenix-demo/mongobleed-exploit-CVE-2025-14847/tree/main/code-sca

The PoC:

• negotiates compression
• sends crafted compressed messages
• iterates offsets
• dumps leaked memory fragments to disk and saves it locally

No credentials required.

No malformed packets.

Repeatable probing.

What actually leaks

Heap memory is messy. That is the point.

Observed and expected leak content includes:

• database credentials
• SCRAM material
• session tokens
• API keys
• WiredTiger config strings
• file paths
• container metadata
• client IPs and connection details
• fragments of recently processed documents

The PoC output already shows real runtime artifacts.

This is not RCE, but steals pieces of memory, which is not as bad as RCE but still very dangerous (Heartbleed anyone)

MongoBleed does not provide native remote code execution.

There is no instruction pointer control. No shellcode injection. No crash exploitation.

What it provides is privilege discovery.

Memory disclosure enables:

• credential reuse
• token replay
• service-to-service authentication
• CI/CD compromise
• cloud control plane access

A leaked Kubernetes token is better than RCE.

A leaked CI token is persistent RCE.

A leaked cloud role is full environment control.

This is RCE-adjacent through legitimate interfaces.

How widespread is this

MongoDB is everywhere.

Shodan telemetry captured on 29 December 2025 shows:

213,490 publicly reachable MongoDB instances

Version breakdown (port 27017):

Version	Count	Query
All versions	201,659	product:"MongoDB" port:27017
8.2.x	3,164	"8.2."
8.0.x (≠8.0.17)	13,411	"8.0." -"8.0.17"
7.0.x (≠7.0.28)	19,223	"7.0." -"7.0.28"
6.0.x (≠6.0.27)	3,672	"6.0." -"6.0.27"
5.0.x (≠5.0.32)	1,887	"5.0." -"5.0.32"
4.4.x (≠4.4.30)	3,231	"4.4." -"4.4.30"
4.2.x	3,138	"4.2."
4.0.x	3,145	"4.0."
3.6.x	1,145	"3.6."

Most are directly exposed on the default port, not shielded behind application tiers.

Core behaviors that matter

• Unauthenticated Any client can trigger it.
• Remote and repeatable Memory offsets can be probed over time.
• Low noise No crashes. Logs stay quiet.
• Data agnostic Whatever was on the heap becomes fair game.

This favors patient actors and automation.

Detection guidance

IOC Identification Network-level signals

Look for:

• Inbound traffic to port 27017
• compressed MongoDB messages
• Repeated requests with:
  • large declared uncompressedSize
  • small actual payloads
• high request frequency without auth attempts

Process-level signals

Watch for:

• elevated CPU on mongod without query load
• repeated short-lived connections
• memory allocation spikes
• abnormal BSON parsing warnings

Post-leak fallout

Check for:

• new MongoDB users
• role changes
• admin command usage anomalies
• auth attempts from unfamiliar IPs
• API key failures
• cloud IAM abuse
• new outbound connections

If you see filesystem artifacts or shells, you are already past exploitation.

Temporary protections

If you cannot upgrade immediately:

• Disable zlib compression Remove zlib from networkMessageCompressors
• Restrict network access Remove direct internet exposure Enforce allowlists

These are stopgaps. The bug lives in the server - hence patch

Tooling and validation

A full test suite is available, combining:

• exploit lab (vulnerable + patched instances)
• network scanner
• code scanner for repos and Dockerfiles

Repository:

https://github.com/Security-Phoenix-demo/mongobleed-exploit-CVE-2025-14847

This allows:

• safe reproduction
• exposure validation
• pre-deployment detection

Why this one matters

MongoBleed does not break crypto it breaks data and memory

The database trusts client-supplied lengths.

Attackers live for that assumption.

Databases are part of your application attack surface.

Infrastructure bugs leak application secrets.

Vulnerability management without reachability is incomplete.

Patch this.

Then ask why it was reachable.