MongoBleed - CVE-2025-14847
CVE-2025-14847 – MongoBleed
Overview
MongoBleed (CVE-2025-14847) is a MongoDB server-side memory disclosure vulnerability that can result in plaintext fragments of application data persisting in MongoDB process memory. Under specific runtime conditions, portions of previously processed BSON documents—including sensitive fields—may remain resident in memory and become observable through crash dumps, diagnostic artifacts, or forensic memory analysis.
CVSS v3.1 score: 8.7 (High)
This vulnerability is not an injection flaw, logic error, or direct remote read issue. It stems from improper memory lifecycle management during BSON decompression and buffer reuse in normal MongoDB operations.
8.2
8.2.0 – 8.2.2
8.2.3
8.0
8.0.0 – 8.0.16
8.0.17
7.0
7.0.0 – 7.0.27
7.0.28
6.0
6.0.0 – 6.0.26
6.0.27
5.0
5.0.0 – 5.0.31
5.0.32
4.4
4.4.0 – 4.4.29
4.4.30
4.2
All versions
No fix (EOL)
4.0
All versions
No fix (EOL)
3.6
All versions
No fix (EOL)
Technical Details
The issue arises when MongoDB processes compressed BSON payloads with network compression enabled (zlib). Compression is a mandatory prerequisite for exposure.
During normal operation, MongoDB decompresses incoming or outgoing BSON documents into internal memory buffers for query execution, updates, and replication. Under certain workloads, these buffers may be reused without being fully cleared before subsequent use.
As a result, residual data from previously processed BSON documents can persist in process memory after the originating operation has completed. If these memory regions are later accessed via crash dumps, diagnostic tooling, memory scraping, or post-incident forensic analysis, fragments of real application data may be recovered. Because the leaked data originates from valid BSON, recovered fragments may resemble well-formed JSON structures.
The vulnerability does not require malformed input, invalid queries, or elevated privileges. The affected data has already passed authentication, authorization, and encryption-at-rest controls, making this a post-processing memory exposure rather than an access control failure.
Conditions Required for Exposure
All of the following conditions must be met for MongoBleed to manifest:
MongoDB is running a vulnerable version listed above
Network compression is enabled using zlib
BSON documents are compressed and decompressed during normal database operations
Internal decompression buffers are reused without full memory clearing
An attacker is able to establish network-level interaction with the MongoDB service
The likelihood and volume of residual data exposure increase under the following operational patterns:
Large or high-entropy BSON documents
Frequent updates or document rewrites
Sustained write-heavy workloads
Long-lived MongoDB processes with high buffer reuse
Impact
Successful exploitation may result in partial disclosure of application-level data residing in MongoDB process memory. The exposed data can include fragments of previously processed BSON documents and may contain sensitive fields, depending on workload characteristics and document structure.
MongoBleed does not provide a direct mechanism to request arbitrary memory contents or bypass MongoDB’s authorization model. Instead, data exposure occurs as a side effect of legitimate database operations and internal memory reuse. An attacker with network access to a vulnerable MongoDB instance may be able to trigger and observe residual in-memory data under specific operational conditions, without requiring malformed queries or elevated privileges.
Credits
Hamid Kashfi (@hkashfi)
Joe Desimone - x.com/dez_
PoC || GTFO
The proof-of-concept generates heavy database traffic and is intended for controlled environments only. Unless specifically requested, I would not use this in a penetration test due to the heavy log pollution.
To validate this vulnerability, a minimal Node.js web application backed by a vulnerable MongoDB instance was implemented. The application is intentionally inefficient and designed to generate a high volume of database activity in order to increase the likelihood of residual memory exposure. Load is then generated using locust, simulating repeated user password reset workflows and producing sustained write-heavy operations against the database.
Build the environment
Clone and run any of the available MongoBleed script(s).
Simulate load.
After running the MongoBleed script alongside the load simulator for several minutes, analysis of the resulting binary output should reveal fragments of sensitive JSON data.
Last updated