CVE-2025–14847 —MongoBleed

CVE-2025–14847, also known as MongoBleed, is a vulnerability that allows attackers to perform unauthorized data reads from the heap memory space of the server on which the MongoDB database runs, without authentication.

MongoDB is a document-based, open-source NoSQL database. It enables the storage of data in different formats such as JSON, BSON, or XML, and allows operations such as searching, deleting, updating, and similar actions to be performed on the stored data.

Pre-Analysis

MongoDB uses a socket-based protocol called MongoDB Wire Protocol for operations performed between the client and server. After a connection is established between the client and server through the MongoDB Wire protocol, communication is carried out by sending/receiving message packets called OP_MSG. Although the OP_MSG format has a standard structure, it can be flexible depending on the type of operation to be performed.

OP_MSG {
    MsgHeader header;           // standard message header
    uint32 flagBits;            // message flags
    Sections[] sections;        // data sections
    optional<uint32> checksum;  // optional CRC-32C checksum
}

struct MsgHeader {
    int32   messageLength; // total message size, including this
    int32   requestID;     // identifier for this message
    int32   responseTo;    // requestID from the original request
    int32   opCode;        // message type
}

Customization of the network protocol and message structure is one of the highly important matters for enabling large-scale data transfers between client and server to be performed efficiently. Mongo uses the OP_COMPRESSED packet standard for the transmission of data in compressed form between client and server structures.

The OP_COMPRESSED message structure is as follows.

struct {
    MsgHeader header;            // standard message header
    int32  originalOpcode;       // value of wrapped opcode
    int32  uncompressedSize;     // size of deflated compressedMessage
    uint8  compressorId;         // ID of compressor that compressed message
    char    *compressedMessage;  // opcode itself, excluding MsgHeader
}

Among the parameters transmitted from the client to the server, information such as compressorId and compressedMessage is sent, which includes the algorithm and message information to be used during the decompression of the compressed data. When examining the other parameters, it is observed that there is one parameter that draws attention - uncompressedSize. The parameter description is "the size of space that the compressed data sent from the client to the server will occupy in memory after being decompressed on the server." So, is this parameter actually being used?

Vulnerability Analysis — Part 1

For the decompression operations performed within Mongo, the decompressMessage function located in src/mongo/transport/message_compressor_manager.cpp is used. Based on the compressorId value sent by the client, it is selected which of the methods defined in the system will be used -- noop, snappy, zlib

The first point that draws attention within the decompressMessage method is that memory space is allocated equal to the size specified by the user through the uncompressedSize parameter. In the next step, the decompressData method belonging to the selected compression method is called. The code block below belongs to the decompressData function of the zlibcompression method, where the relevant vulnerability was detected.

On line 72, the memory size value transmitted by the client through the uncompressedSize parameter is transferred to the length parameter. On line 73, the file content size sent by the client, the file content, and the estimated memory space information also determined by the client are sent to the uncompress method located in src/third_party/zlib/uncompr.c. The point that needs to be noted here is that the memory size amount provided by the client is transferred to the uncompress method in the form of a reference variable &length.

After the operations performed within the uncompress method, the data sent by the user is passed through the decompressionprocess, and the resulting data size is calculated and transferred to the destLen parameter. The destLen parameter was storing the reference/address information of the length parameter located within the decompressData method, thus we see that as a result of the operation, the uncompressedSize value sent by the client is replaced by calculating the size of the file also provided by the client.

However, when we reach line 83, we encounter the root cause of the CVE-2025–14847 vulnerability. After the actual size of the data transmitted by the client is calculated by the uncompress method on line 73 and transferred to the lengthparameter, it is observed that the output.length() method, whose content is determined by the client, is being used. This situation causes data of a size determined by the client to be read from the heap memory space belonging to the server, and this data to be transmitted to the client as a response as if it were the result of a decompression operation.

Any information that has been stored recently can be found within the read heap memory space. For example: username, password, token, system configuration information, and more.

So, how is the content of the allocated memory space on the target system transmitted to the client as a response?

Vulnerability Analysis — Part 2

Objects within Mongo are transmitted to the client or received from the client by being serialized/deserialized with a format called BSON - Binary JSON.

As a result of using the decompressMessage method in src/mongo/transport/message_compressor_manager.cpp with zlib, it is observed that the memory space of a size determined by the client is returned as the result.

In the next step, the value within the allocated memory space is converted to BSON format and transmitted to the client.

BSON values are stored as key-value pairs. Before BSON responses are transmitted to the client by Mongo, the fields they contain are parsed. During this process, the information that a value has terminated is detected by checking the \0 (null-terminator) value from the C language. During the parsing process, all values retrieved until the \0 value is encountered are assumed to belong to the BSON object.

The memory space to be converted to BSON format contains the data in BSON format that was transmitted by the client. In cases where the BSON content sent by the client does not end with the \0 value, Mongo starts searching for the \0 value within the memory space read at the size determined by the client. Since the \0 value will belong to a different piece of data, the read value will not be a valid BSON object and an error message will be thrown. This thrown error message contains and leaks the values found within the memory space whose size was determined by the client.

Exploit

Performing reads from the memory space with requests sent one by one will not be very practical. For this reason, a small application will be developed to enable the reading operation to be performed from the target system’s memory space.

You can access both the vulnerable machine and the application developed for unauthorized data reading from the target system within PeakCyber Github.

Solution

Considering the impact of the detected vulnerability, it is observed that its fix was implemented in a very simple manner — Fix Commit

It is observed that the vulnerability was fixed by using the actual length information of the decompressed file during the decompressData operation located within the src/mongo/transport/message_compressor_zlib.cpp class.

Note — The Commit from 2017 that caused the vulnerability — The Jira Task opened for the resolution of the vulnerability

Effected Versions

Following MongoDB versions are effected by Mongo Bleed vulnerability.

— 8.2.x — 8.2.2 — 8.0.x — 8.0.16 — 7.0.x — 7.0.27 — 6.0.x — 6.0.26 — 5.0.x — 5.0.31