# 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. | MongoDB Major Version | Vulnerable Versions | Fixed Version | | --------------------- | ------------------- | ------------- | | 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) | [MongoDB fix commit](https://github.com/mongodb/mongo/commit/505b660a14698bd2b5233bd94da3917b585c5728) ### 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\_](https://x.com/dez_) *** ## PoC || GTFO {% hint style="danger" %} 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. {% endhint %} 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. 1. Build the environment 
git clone git@github.com:0xPThree/mongobleed-test-environment.git
python3 -m venv venv
source venv/bin/activate
pip install -r requirements.txt
docker compose up --build
2. Clone and run any of the available MongoBleed script(s). ```bash git clone https://github.com/Hamid-K/mongobleed.git cd mongobleed python3 mongobleed.py --host 127.0.0.1 --port 27017 --max-offset 15000 --loop ``` 3. Simulate load. ```bash locust -f traffic-sim.py --host http://127.0.0.1:3000 --users 20 --spawn-rate 2 --headless --run-time 2m ``` 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.

Image 01: Canceling MongoBleed script.

Image 02: Raw memory output, grepping for "pass".

Image 03: Parsed memory output.

--- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://0xpthree.gitbook.io/notes/exploits-pocs/mongodb/mongobleed-cve-2025-14847.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.