Experiencing a Cyber Incident? Our DFIR team is on standby 24/7.
IR Hotline: +30 210 700 1331
Contact Now
Book a Consultation
  • Home
  • Blog & Update: MongoBleed: Unauthenticated MongoDB Heap Memory Disclosure (CVE-2025-14847)

MongoBleed: Unauthenticated MongoDB Heap Memory Disclosure (CVE-2025-14847)

  • Unit 13

Jump to section

Jump to section

Untitled design 8 
Unit 13 Field Report. Technical analysis by ThreatScene's Unit 13 - Red Team.

Author Credits
- Konstantinos Kostakis, Senior Offensive Security Consultant @ Unit 13

TL;DR

Publicly exposed MongoDB instances are vulnerable to an unauthenticated heap memory disclosure that can leak sensitive data from the database process. The issue affects a wide range of MongoDB versions and can be exploited remotely without credentials. All supported MongoDB deployments should be patched immediately. End-of-life versions must be upgraded, as no fixes will be provided.

Overview

On 19 December 2025, MongoDB’s security research team disclosed a critical vulnerability in the MongoDB server, tracked as CVE-2025-14847. The flaw allows an unauthenticated attacker to craft a malicious wire protocol message that causes MongoDB to read beyond the bounds of a BSON document and return fragments of heap memory in error responses.

Because the leaked memory originates from the MongoDB process heap, it may contain remnants of previously processed data, including document fields, query data, internal variables, or other sensitive information handled by the database. The memory disclosure continues until a null byte is encountered, making the amount and content of leaked data unpredictable.

The vulnerability has been informally named MongoBleed due to its strong resemblance to the Heartbleed vulnerability disclosed in 2014, where malformed length fields allowed attackers to read arbitrary process memory from OpenSSL. As with Heartbleed, MongoBleed enables passive data exfiltration without authentication, logging, or modification of server state.

Image3
Data leakage using the public available POC.

Impact and Real-World Exploitation

MongoBleed results in a high confidentiality impact, with no direct integrity or availability effects. The vulnerability has been assigned a CVSS v3.1 score of 7.5 and a CVSS v4.0 score of 8.7, reflecting the ease of exploitation and the sensitivity of the data that may be exposed.

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N

CVSS vectors and score

This issue is not theoretical. Public reporting has already linked real-world attacks to this vulnerability, including an incident involving Ubisoft’s Rainbow Six Siege infrastructure, where attackers reportedly gained access to backend database systems and manipulated in-game values after compromising exposed MongoDB services.

At present, the public proof of concept is limited and only discloses data up to the first null byte, which terminates the string. This may change in the future if a more advanced proof of concept is developed. This is why you should patch immediately to prevent any unauthorized access to your data.

Any MongoDB instance that is internet-accessible and supports compressed (zlib) wire protocol messages is a viable target. Censys reported around 86.000 vulnerable hosts.

Image4

Vulnerable hosts reported by Censys

Technical Overview

MongoDB communicates using a custom binary wire protocol over TCP, typically on port 27017. The protocol follows a request–response model and defines several message types, including OP_MSG for standard client requests and OP_COMPRESSED for compressed payloads.

Compression support was added to MongoDB to reduce bandwidth usage and improve performance. However, the vulnerability originates from a logic flaw in the zlib decompression handling code introduced in June 2017. Specifically, the server trusts attacker-controlled size fields when allocating memory for decompressed messages.

To exploit MongoBleed, an attacker sends an OP_COMPRESSED message containing an embedded OP_MSG. The attacker controls the uncompressedSize field, which specifies how large the message will be after decompression. MongoDB allocates a buffer based on this value before performing decompression.

The compressed payload itself contains a very small BSON document. Critically, the BSON document’s internal documentLength field is inflated to indicate that more data exists than is actually present. This mismatch causes the BSON parser to continue reading past the legitimate end of the BSON document and into adjacent heap memory.

At a high level, the message structure looks as follows:

+------------------------------------------------------+
|                   OP_COMPRESSED Header               |
+------------------------------------------------------+
| messageLength = 16 (Header size) + OP_COMPRESSED Body|
| requestID     = 1                                    |
| responseTo    = 0                                    |
| opCode        = 2012  (OP_COMPRESSED)                |
+------------------------------------------------------+

+------------------------------------------------------+
|                OP_COMPRESSED Body                    |
+------------------------------------------------------+
| originalOpcode   = 2013  (OP_MSG)                    |
| uncompressedSize = 8192  <---- Attacker controlled   |
| compressorId     = 2     (zlib)                      |
+------------------------------------------------------+
| compressedMessage = zlib compressed (BSON data)      |
+------------------------------------------------------+

Once decompressed, the BSON parser processes the malformed document:

Uncompressed BSON Data
+-------------------------------+
| int32 documentLength          |
| Attacker controlled           |
+-------------------------------+
| 0x10                          |
| BSON type: int32              |
+-------------------------------+
| 0x61                          |
| field name: 'a'               |
+-------------------------------+
| 0x00                          |
| field name terminator         |
+-------------------------------+
| 0x01 0x00 0x00 0x00           |
| int32 value = 1               |
+-------------------------------+
| 0x00                          |
| BSON document terminator      |
+-------------------------------+
| No actual data here, but the  |
| parser believes more BSON     |
| exists due to inflated length |
+-------------------------------+

Because the declared documentLength exceeds the real BSON payload, the parser continues scanning memory for additional field names. It interprets arbitrary heap data as BSON field names until a null byte is encountered or the end of the allocated buffer is reached.

The leaked memory is then reflected back to the client in an error response similar to the following:

{
  "ok": 0,
  "errmsg": "invalid BSON field name '<leaked heap memory bytes>\0'"
}

This behavior forms the core MongoBleed primitive: controlled overreads of heap memory triggered by mismatched length fields in compressed BSON messages.

Image1 1

Commit from 1 June 2017 that introduced the vulnerable zlib decompression logic.

Image2

Commit that fixes the vulnerability by enforcing stricter bounds checking.

Mitigation

MongoDB has released fixes for all supported branches. The vulnerability is resolved in the following versions:

  • MongoDB 4.4.30
  • MongoDB 5.0.32
  • MongoDB 6.0.27
  • MongoDB 7.0.28
  • MongoDB 8.0.17
  • MongoDB 8.2.3

The following versions are vulnerable:

  • MongoDB 8.2.0 through 8.2.2
  • MongoDB 8.0.0 through 8.0.16
  • MongoDB 7.0.0 through 7.0.26
  • MongoDB 6.0.0 through 6.0.26
  • MongoDB 5.0.0 through 5.0.31
  • MongoDB 4.4.0 through 4.4.29
  • All MongoDB Server v4.2 versions
  • All MongoDB Server v4.0 versions
  • All MongoDB Server v3.6 versions

MongoDB versions 4.0, 4.2, and earlier are end of life and will not receive security updates. If you are running these versions, upgrading is the only viable mitigation. Approximately 20 percent of MongoDB deployments are estimated to still be running unsupported versions, leaving a significant attack surface exposed.

All MongoDB servers should be upgraded to a fixed version as soon as possible. In addition to applying patches, administrators should ensure that MongoDB instances are not directly exposed to the internet. If patching is not immediately possible, zlib compression can be disabled as a mitigation for this vulnerability

Detection Logic

The exploit generates a very high volume of short-lived connections to probe for memory disclosure, while never sending client metadata, which is consistently present in legitimate MongoDB driver traffic. This behavior enables reliable detection by correlating connection volume with the absence of metadata in MongoDB JSON logs.

The logic parses MongoDB log entries related to new connections (event ID 22943) and client metadata (event ID 51800). Connections are aggregated per source IP within a defined time window, after which the metadata presence rate is calculated. Legitimate drivers typically include metadata in approximately 90–100% of connections, whereas exploit traffic consistently shows a 0% metadata rate.

In parallel, the connection velocity is calculated. Normal environments exhibit very low connection rates, while exploitation attempts reach on the order of 100,000 or more connections per minute. Source IPs that simultaneously exhibit extreme connection velocity and a complete absence of metadata are flagged as likely exploitation attempts.

Conclusion

MongoBleed is a severe and elegant vulnerability that demonstrates how subtle length validation issues in binary protocols can lead to catastrophic data exposure. Its similarity to Heartbleed underscores the long-term risk of trusting attacker-controlled size fields in low-level parsing code.

Organizations running MongoDB should treat this issue as a priority incident. Patch immediately, audit exposure, and assume that any publicly accessible, unpatched instance may already be compromised.

References

If you like this article valuable, you can share it with your network

Recent Posts