top of page
Search

MongoBleed: Pre-Auth Memory Disclosure via OP_COMPRESSED in MongoDB (CVE-2025-14847)

CVE-2025-14847 is a remotely exploitable information disclosure vulnerability affecting MongoDB Server. The flaw exists in the server’s network message handling logic and can be triggered before authentication, making it reachable by any client that can establish a network connection to the MongoDB service.


MongoDB uses a custom binary wire protocol over TCP for all client–server communication. To reduce bandwidth usage, the protocol supports optional message compression, including zlib. When compression is enabled, client messages are encapsulated using a special wrapper opcode, OP_COMPRESSED, which instructs the server how to decompress and process the enclosed payload.


The vulnerability arises from improper handling of length metadata supplied in zlib-compressed protocol messages. Under certain conditions, MongoDB allocates a buffer for decompression based on client-provided size information, but does not ensure that the entire buffer is fully initialized after decompression. If the actual decompressed payload is smaller than the declared size, portions of the buffer may contain residual heap data from prior memory usage.


In vulnerable versions, this partially uninitialized buffer may later be treated as valid message data and incorporated into responses sent back to the client. As a result, raw heap memory contents can be disclosed to an unauthenticated remote attacker.

This issue occurs at a low level in the request handling pipeline, during message parsing and decompression, before authentication, authorization, or query execution logic is reached. Consequently, even deployments with authentication enabled may be affected if the MongoDB service is network-reachable and compression is permitted.


The impact of this vulnerability is limited to information disclosure rather than direct code execution. However, leaked heap memory may contain sensitive data such as fragments of credentials, authentication tokens, connection strings, or recently processed user data, depending on server activity and memory reuse patterns.

This write-up examines the vulnerability from a technical perspective, beginning with the MongoDB wire protocol design, then focusing on compressed message handling, and finally explaining how an unchecked assumption in buffer management leads to cross-boundary memory exposure.


Understanding MongoDB and the Affected Component


MongoDB is a document-oriented NoSQL database implemented primarily in C++. It runs as a long-lived server process (mongod) that listens for client connections, receives binary messages over the network, decodes them, and dispatches the resulting commands to the appropriate execution paths.


Unlike HTTP-based services, MongoDB does not use text-based request formats such as JSON over REST. All client interaction occurs through a custom binary wire protocol designed for performance and low overhead. This protocol is processed directly over TCP and is handled very early in the server’s execution flow, before any security checks related to users or permissions are applied.


MongoDB wire protocol overview

Each client request sent to MongoDB consists of a binary message with:

  • a fixed-size message header

  • an opcode identifying the message type

  • a payload containing command data


Modern MongoDB deployments primarily use the OP_MSG opcode. However, the protocol also supports OP_COMPRESSED, which acts as a wrapper around other message types to allow compression at the transport layer.

When compression is enabled, clients do not send OP_MSG directly. Instead, the message flow is:

OP_COMPRESSED → compressed(OP_MSG payload)

The server must first decompress the message before it can perform any further processing.


Where compression fits in the execution flow

The vulnerable logic is executed in the network receive path, prior to:

  • authentication checks

  • authorization and role evaluation

  • database or collection access

  • query parsing and execution

At a high level, the flow is:

socket read→ parse message header→ identify OP_COMPRESSED→ allocate buffer for decompression→ decompress payload→ forward resulting message to standard command handling


The flaw exists entirely within this decompression stage.


The Affected Component: zlib-Compressed Message Handling


An OP_COMPRESSED message includes metadata describing the compression algorithm used and the expected size of the message after decompression. This size information is provided by the client and is intended to guide the server’s decompression process.


In vulnerable MongoDB versions, this metadata influences how much memory the server allocates on the heap before invoking the zlib decompressor. If the compressed payload expands to fewer bytes than indicated by the supplied size values, the decompressor initializes only part of the allocated buffer.


The remaining portion of the buffer is left in an uninitialized state and may contain residual data from previous heap allocations. Subsequent handling of the decompressed message may rely on the declared size rather than the actual number of bytes written during decompression, causing uninitialized heap contents to be included in data returned to the client.


Why This Is a Low-Level and Dangerous Bug

This vulnerability is not an application-layer logic error. It is a memory safety issue in MongoDB’s core networking code:

  • it affects all databases hosted by the server

  • it is reachable without authentication

  • it is triggered before user or permission checks

  • it is implemented in C++, where memory is not automatically zeroed


Because the flaw exists in the wire protocol parsing layer, traditional database-level security controls such as users, roles, and access restrictions do not mitigate the issue once the MongoDB port is reachable and compression is enabled.


In essence, the affected component is not “MongoDB queries” or “MongoDB users,” but the binary message decompression and buffer management logic that sits at the very front of the server’s request processing pipeline.


Affected Products and Fixed Versions

CVE-2025-14847 affects MongoDB Server across multiple major release branches. According to public advisories, the vulnerability impacts all versions prior to the following fixed releases in supported branches:

  • MongoDB Server 8.2: fixed in 8.2.3

  • MongoDB Server 8.0: fixed in 8.0.17

  • MongoDB Server 7.0: fixed in 7.0.28

  • MongoDB Server 6.0: fixed in 6.0.27

  • MongoDB Server 5.0: fixed in 5.0.32

  • MongoDB Server 4.4: fixed in 4.4.30


Older, end-of-life branches such as MongoDB Server 3.6, 4.0, and 4.2 are also affected. These branches do not receive in-line security patches, and remediation requires upgrading to a supported, fixed major version.


Threat Model and Exploitability


Threat model


The attacker model for CVE-2025-14847 is minimal.

An attacker only requires remote network access to a running MongoDB Server (mongod) instance. No authentication credentials are required, no valid MongoDB user account is needed, and no database-level permissions are involved.


If a client can establish a TCP connection to the MongoDB service port (default 27017) and communicate using the wire protocol with compression enabled, the vulnerable code path is reachable immediately. The flaw is triggered during message parsing and decompression, before authentication, authorization, or command parsing logic is executed.


As a result, the attacker does not need:

  • a username or password

  • membership in a replica set

  • administrative or read privileges

  • access to any specific database or collection


The sole requirement is network reachability to the MongoDB service.

From a security boundary perspective, this vulnerability crosses a hard trust boundary: raw server heap memory is exposed to an unauthenticated external client.


Why real-world exploitation is realistic


Several factors make CVE-2025-14847 practical to exploit in real deployments.

First, MongoDB instances are frequently exposed to the internet, either intentionally or through misconfiguration. Despite long-standing guidance, it remains common to find MongoDB services listening on public IP addresses in cloud environments, VPS deployments, and small production setups. In such cases, the wire protocol is directly reachable from the internet.


Second, the vulnerable behavior is repeatable and low-noise. This is not a race condition or a single-crash scenario. An attacker can send multiple crafted compressed messages and receive responses that may include different heap fragments over time. Each request can potentially leak new memory contents depending on allocator state and server activity.


Third, exploitation does not depend on complex heap grooming. While the exact contents of leaked memory are nondeterministic, the vulnerability does not require precise memory layout manipulation to demonstrate impact. Even simple probing can return heap data that clearly does not belong to the attacker’s request.


Fourth, compression is a normal and supported feature of MongoDB. The attack does not rely on undefined protocol behavior or malformed packets that would immediately stand out as anomalous. The server processes the messages as valid OP_COMPRESSED frames and follows its standard decompression logic.


Finally, the flaw resides in core networking code that is exercised early and frequently. It is not gated behind optional modules or rarely used features. Any MongoDB server with compression enabled consistently exposes this attack surface.


Practical impact from an attacker’s perspective


CVE-2025-14847 is an information disclosure vulnerability, not direct remote code execution. However, the leaked data originates from the server’s heap and may include:

  • fragments of credentials or authentication tokens

  • connection strings

  • pieces of recently processed queries

  • BSON documents or document fragments

  • internal server state data


Because the leak occurs before authentication, an attacker can collect this information without generating audit records associated with a specific MongoDB user identity.

In practical terms, this makes the vulnerability useful for:

  • reconnaissance against exposed databases

  • passive data harvesting

  • extracting sensitive material from otherwise authenticated deployments

  • chaining with other vulnerabilities or misconfigurations


Exploitability summary

CVE-2025-14847 is exploitable with:

  • remote network access only

  • no authentication

  • no special privileges

  • no user interaction


Its real-world practicality stems from widespread exposure, protocol-level reachability, and the ability to repeatedly trigger memory disclosure. While it does not grant code execution, the nature of the leaked data makes it a high-impact vulnerability in real MongoDB deployments.


Root Cause Summary

The root cause of CVE-2025-14847 is a mismatch between attacker-controlled size metadata in the MongoDB wire protocol and how the server allocates and subsequently uses heap memory during message decompression.


MongoDB supports network-level compression by wrapping standard protocol messages inside an OP_COMPRESSED container. This container includes metadata that describes how the compressed payload should be processed. One of these fields indicates the expected size of the message after decompression.


This size value is fully controlled by the client. The server does not derive it independently from the compressed data; it relies on the value provided in the protocol message.


When a compressed message is received, MongoDB performs the following high-level steps:

First, it parses the OP_COMPRESSED header and reads the declared uncompressed size. Next, it allocates a heap buffer sized according to this value.Then, it passes the compressed payload and the allocated buffer to the zlib decompressor.

The critical flaw is that MongoDB does not enforce that the number of bytes actually written by the decompressor matches the declared size. If the compressed payload expands to fewer bytes than claimed, zlib initializes only part of the allocated buffer. The remaining portion of the buffer is left uninitialized and may contain residual data from previous heap allocations.


Later in the message handling pipeline, MongoDB treats this buffer as fully valid. When the server copies, parses, or serializes the message using the declared size rather than the actual decompressed length, uninitialized heap data may be included in data sent back to the client.


This results in disclosure of raw heap memory across the network boundary.

In short, the vulnerability is not in zlib itself, but in MongoDB’s trust model around protocol metadata. By trusting attacker-controlled size values to drive memory allocation and subsequent data handling, MongoDB creates a memory safety violation that allows heap contents to be exposed to unauthenticated remote clients.


5. Deep Technical Analysis


5.1 Wire protocol background: OP_MSG vs OP_COMPRESSED


MongoDB does not use HTTP or any text-based protocol. All communication between a client and the server occurs over a custom binary wire protocol carried directly over TCP. Every request and response is a binary message consisting of a fixed-size header followed by an opcode that defines how the payload should be interpreted.

The primary and modern opcode used by MongoDB is OP_MSG. OP_MSG carries database commands encoded as BSON and represents the format the server ultimately expects to parse and execute.


To reduce bandwidth usage, MongoDB supports network-level message compression. Compression is not applied to individual fields or documents. Instead, the entire wire-protocol message is wrapped inside a transport-level opcode called OP_COMPRESSED.

OP_COMPRESSED is not a database command. It is a transport wrapper whose sole purpose is to describe how to recover the original message.

An OP_COMPRESSED message contains:


  • the original opcode (typically OP_MSG)

  • the compression algorithm identifier (zlib in the affected cases)

  • a field named uncompressedSize

  • the compressed byte stream


When the server receives a message, it first examines the opcode. If the opcode is OP_COMPRESSED, the server must fully decompress the payload before it can determine which command the client is attempting to execute.

This places decompression at the very front of the request-handling pipeline, before:

  • authentication

  • authorization

  • command parsing

  • database access

As a result, any flaw in this stage is reachable by unauthenticated network clients.


5.2 Vulnerable code path: parse → allocate → decompress → construct message / response


The vulnerable execution path can be broken down into four logical stages.


Step 1: Parse the compressed message header

When the server reads an incoming message and identifies the OP_COMPRESSED opcode, it parses the compression metadata, including the uncompressedSize field. This value is supplied entirely by the client and is not derived from the compressed payload.


Step 2: Allocate a buffer for decompression

MongoDB allocates a heap buffer large enough to hold the decompressed message. The size of this allocation is taken directly from the client-provided uncompressedSize value.

At this point, the server implicitly assumes that the declared size accurately reflects the number of bytes that will be produced during decompression.


Step 3: Decompress the payload

The server passes the compressed payload and the allocated output buffer to the zlib decompressor. zlib inflates the compressed data and writes the result into the provided buffer.

Crucially, zlib does not guarantee that it will write exactly the number of bytes requested by the caller. It writes only as many bytes as are produced by decompression and reports the actual number of bytes written via its output state.


Step 4: Construct the inner message and response

After decompression, MongoDB treats the output buffer as a complete wire-protocol message and forwards it to the normal message parsing logic.

If parsing fails, for example due to malformed BSON or an invalid message structure, MongoDB constructs an error response. In several error-handling paths, portions of the original request buffer may be included in the response for diagnostic or contextual purposes.

This is the point at which heap memory crosses the trust boundary.


5.3 The core failure: trusted length, allocation, and mismatch


The core failure is not in zlib itself. It is a length-handling error in MongoDB’s protocol implementation.


Two distinct lengths exist in this code path:

Declared lengthThe uncompressedSize field supplied by the client in the OP_COMPRESSED header.

Actual lengthThe number of bytes actually written into the buffer by the zlib decompressor.


MongoDB allocates memory using the declared length. This alone is not inherently unsafe. The vulnerability arises because, after decompression, MongoDB continues to treat the declared length as the size of valid data, rather than the actual number of bytes produced during decompression.


In vulnerable implementations, downstream code propagates the buffer size rather than the true decompressed byte count. As a result, later stages of message handling operate under the assumption that the entire buffer contains valid message data, even though only part of it was initialized.


This creates a mismatch between:

  • how much memory was initialized by zlib

  • how much memory MongoDB believes is safe to read, parse, or copy


5.4 Why this leaks memory: byte-level flow from heap to network

This vulnerability leaks memory because uninitialized heap bytes are treated as valid protocol data and propagated into server responses.


At a high level, the byte-level flow is:

  • The attacker sends a compressed message with an inflated uncompressedSize.

  • MongoDB allocates a heap buffer of that size.

  • zlib inflates the payload and writes fewer bytes than allocated.

  • The remainder of the buffer contains residual heap data from prior allocations.

  • MongoDB treats the entire buffer as a valid decompressed message.

  • When parsing fails or an error response is generated, parts of the request buffer are included in the response.

  • The response sent back to the client contains bytes from the uninitialized tail of the heap buffer.


This is not a theoretical condition. It is a direct consequence of using the declared size rather than the actual decompressed length when propagating buffer contents.

Because this occurs before authentication, no credentials are required. Because the behavior is repeatable, an attacker can issue multiple crafted requests and collect different heap fragments over time, depending on allocator state and server activity.


Static analysis


This vulnerability can be fully demonstrated through static source-code analysis by following the flow of attacker-controlled data from the MongoDB wire protocol into heap allocation, decompression, and message reconstruction.


1. Attacker-controlled fields in the wire protocol

File: src/mongo/rpc/op_compressed.h

MongoDB parses the OP_COMPRESSED wire protocol header using the CompressionHeader struct:

struct CompressionHeader {
    std::int32_t originalOpCode;
    std::int32_t uncompressedSize;
    std::uint8_t compressorId;
};

The parsing constructor reads these fields directly from the network buffer:

CompressionHeader(ConstDataRangeCursor* cursor) {
    originalOpCode = cursor->readAndAdvance<LittleEndian<std::int32_t>>();
    uncompressedSize = cursor->readAndAdvance<LittleEndian<std::int32_t>>();
    compressorId = cursor->readAndAdvance<LittleEndian<std::uint8_t>>();
}

At this point, uncompressedSize is fully attacker-controlled. The server does not derive it from the compressed payload, nor does it cryptographically verify it. It is trusted metadata supplied by the client.


2. Use of uncompressedSize for heap allocation

File: src/mongo/transport/message_compressor_manager.cppFunction: MessageCompressorManager::decompressMessage

After parsing the CompressionHeader, MongoDB uses uncompressedSize to allocate the output buffer for decompression:

size_t bufferSize =
    static_cast<size_t>(compressionHeader.uncompressedSize) + MsgData::MsgDataHeaderSize;

auto outputMessageBuffer = SharedBuffer::allocate(bufferSize);

This establishes a direct trust relationship:

OP_COMPRESSED.uncompressedSize → heap allocation size

The allocated buffer is then wrapped as a new MsgData structure, and its opcode is set to the original inner opcode:

MsgData::View outMessage(outputMessageBuffer.get());
outMessage.setOperation(compressionHeader.originalOpCode);
outMessage.setLen(bufferSize);

At this stage, the buffer is considered large enough to hold the fully decompressed inner message.


3. Decompression and returned length propagation

File: src/mongo/transport/message_compressor_zlib.cppFunction: ZlibMessageCompressor::decompressData (vulnerable version)

MongoDB delegates decompression to the selected compressor implementation. For zlib, the vulnerable code was:

uLongf length = output.length();
int ret = ::uncompress(..., &length, ...);

return {output.length()};

Although zlib::uncompress() updates length to the actual number of bytes written, the function ignored this value and returned output.length(), which is the buffer capacity, not the real decompressed size.

As a result, the decompressor reported that the entire output buffer was valid decompressed data, even when zlib had written fewer bytes.


4. Failed safety check due to incorrect length reporting

File: src/mongo/transport/message_compressor_manager.cppFunction: MessageCompressorManager::decompressMessage

After decompression, MongoDB attempts to validate the result:

if (sws.getValue() != static_cast<std::size_t>(compressionHeader.uncompressedSize)) {
    return {ErrorCodes::BadValue, "Decompressing message returned less data than expected"};
}

This check is intended to detect malformed compressed messages that inflate to fewer bytes than declared.However, because the zlib decompressor incorrectly returned the buffer capacity (derived from uncompressedSize), this comparison always succeeded, even when the actual decompressed output was smaller.

The safety check was therefore rendered ineffective by incorrect length propagation.


5. Message reconstruction using an incorrect logical length

File: src/mongo/transport/message_compressor_manager.cpp

MongoDB finalizes the reconstructed message length using the decompressor’s returned value:

outMessage.setLen(sws.getValue() + MsgData::MsgDataHeaderSize);

Because sws.getValue() equaled the attacker-controlled uncompressedSize, the server treated the entire buffer as initialized and valid message data.

Any bytes in the tail of the buffer that were not written by zlib remained uninitialized heap memory, but were now included within the logical message bounds.


6. Memory disclosure mechanism

Once the reconstructed message is passed to downstream parsing and error-handling logic, MongoDB may read or copy portions of the request buffer based on the message length. In error scenarios (e.g., malformed inner OP_MSG), portions of the request data may be included in server responses.

Because the logical message length includes unwritten tail bytes, these responses can contain stale heap memory from prior allocations, resulting in pre-authentication remote information disclosure.


7. Patch validation

File: src/mongo/transport/message_compressor_zlib.cpp (patched version)

The fix consists of returning the actual decompressed length reported by zlib:

return {length};

This restores the invariant that only bytes actually written by the decompressor are considered valid. As a result:

  • the length comparison in decompressMessage() becomes effective

  • the reconstructed message length is accurate

  • uninitialized heap bytes are no longer included in message processing


Impact Analysis


What can leak in practice

CVE-2025-14847 results in heap memory disclosure, not arbitrary memory read and not full process memory exposure. The leaked data originates from uninitialized portions of a heap buffer that was allocated for message decompression but not fully written by the zlib decompressor.

In practical terms, the exposed data consists of residual heap contents from prior allocations within the same MongoDB server process.

Data that may leak includes:

  • partial BSON documents from previously processed client requests

  • fragments of earlier wire-protocol messages

  • internal server strings such as command names or error messages• session-related metadata located in adjacent heap regions

  • short-lived sensitive material (for example, authentication tokens or SCRAM-related data), but only if heap reuse and timing align


The leak is non-deterministic. The contents vary based on allocator behavior, server activity, memory reuse patterns, and request timing. Different requests may return different heap fragments even when the same payload is sent repeatedly.


What is realistic vs. what is not guaranteed

What is realistic:

  • repeated small memory disclosures across multiple requests

  • exposure of different heap fragments over time

  • partial correlation of leaked data when requests are issued rapidly

  • disclosure that aids reconnaissance, fingerprinting, or secondary attacks


What is not guaranteed:

  • full memory dumps

  • reliable extraction of complete credentials

  • precise control over which data is leaked

  • arbitrary memory reads

  • immediate privilege escalation on its own


This vulnerability is an information disclosure issue, not memory corruption and not remote code execution. Its risk stems from pre-authentication reachability and repeatability, rather than deterministic attacker control.


Why exploitation is plausible in the real world


Several real-world conditions increase the practical impact of this vulnerability:

MongoDB services are frequently exposed to networks, either intentionally or through misconfiguration.Message decompression occurs before authentication or authorization checks.OP_COMPRESSED is a normal, supported part of the MongoDB wire protocol.The attack uses valid protocol messages rather than malformed network traffic.The leak can be triggered repeatedly to collect multiple heap fragments over time.

Taken together, these factors make the vulnerability useful for reconnaissance and for chaining with other weaknesses, even though each individual disclosure may be small.


Hypothetical exploit scenario (conceptual)

The following is a conceptual sequence illustrating how the vulnerability can be abused. It is not exploit code.

  • An attacker identifies a MongoDB instance that is reachable over the network.

  • The attacker sends a crafted OP_COMPRESSED message where uncompressedSize is larger than the true decompressed payload.MongoDB allocates a heap buffer sized according to uncompressedSize.

  • zlib inflates the payload and writes fewer bytes than allocated.

  • Due to incorrect length handling, MongoDB treats the entire buffer as valid message data.

  • The inner message fails parsing, for example due to malformed BSON.

  • MongoDB constructs an error response that includes portions of the request buffer.

  • Uninitialized heap bytes are copied into the response and sent back to the client.

  • By repeating this process, the attacker can collect different heap fragments across requests.

Over time, this may reveal:

  • recurring memory patterns• partial secrets or identifiers

  • internal metadata

  • data associated with other client activity


No single response guarantees sensitive data, but statistical leakage accumulates over repeated requests, which is sufficient to pose a real security risk in exposed deployments.


Detection and Monitoring


Network-level indicators


At the wire-protocol level, suspicious activity typically manifests as abnormal use of compressed messages early in a connection’s lifecycle.


Key indicators include:

  • a disproportionately high volume of OP_COMPRESSED messages compared to normal OP_MSG traffic

  • compressed requests sent before authentication completes

  • repeated compressed requests that consistently trigger server-side errors

  • compressed messages advertising unusually large uncompressedSize values relative to the actual payload size

  • short-lived TCP connections that send one or two compressed messages and immediately disconnect


In packet captures or protocol-aware inspection tools, this often appears as many small compressed frames followed by error responses, rather than successful command execution.

These patterns are especially suspicious when they originate from unfamiliar IP ranges or occur in bursts.


Exposure checks


Operationally, network exposure is the dominant risk factor, not attacker sophistication.


Defenders should perform the following checks:

  • enumerate all hosts listening on TCP port 27017

  • verify whether any MongoDB instances are reachable from:– the public internet– untrusted or broadly accessible internal networks

  • confirm whether TLS and authentication are enabled

  • review firewall rules, cloud security groups, and load balancer configurations for accidental exposure

Any internet-reachable MongoDB service should be treated as high risk, regardless of authentication settings, because this vulnerability is triggered before authentication logic executes.


Server-side and operational signals

Within MongoDB logs and surrounding infrastructure telemetry, defenders may observe:

  • increased frequency of decompression-related errors

  • repeated parsing failures or messages similar to“Decompressing message returned less data than expected”

  • short, repeated connections from unexpected client IPs

  • error responses generated very early in request handling

  • spikes in network egress without corresponding successful queries


Individually, these signals are weak. When observed together, they may indicate probing or repeated attempts to harvest leaked memory fragments.


Mitigation and Hardening

Immediate mitigations (no code changes)


The following actions significantly reduce risk even before upgrading:

  • Remove internet exposureRestrict TCP port 27017 to trusted IP ranges only. Enforce network-level access controls using firewalls, security groups, or private networking.

  • Disable network compressionRemove zlib (and other compressors if configured) from MongoDB’s enabled compression list. This prevents OP_COMPRESSED from being negotiated at all and removes the vulnerable code path.

  • Enable TLS and authenticationWhile not sufficient on their own, these controls reduce accidental exposure and add defense in depth.


Permanent remediation

The definitive fix is to upgrade to a patched MongoDB version.

The patch corrects length handling in the zlib decompressor so that:

  • only bytes actually written by the decompressor are treated as valid

  • safety checks in the message reconstruction path function as intended

  • uninitialized heap memory is no longer included in server responses

All deployments using zlib compression should upgrade, even if the database is not internet-facing.


References

MongoDB, Inc. (2025). MongoDB server source code (Version affected and patched releases) [Computer software].https://github.com/mongodb/mongo


MongoDB, Inc. (2025). OP_COMPRESSED: MongoDB wire protocol compression specification.https://github.com/mongodb/specifications/blob/master/source/compression/OP_COMPRESSED.md


MongoDB, Inc. (2025). Security advisory for CVE-2025-14847 [Security bulletin].(Use the official MongoDB advisory page when published.)


National Institute of Standards and Technology. (2025). CVE-2025-14847 detail. National Vulnerability Database.https://nvd.nist.gov/vuln/detail/CVE-2025-14847


Deutsch, P., & Gailly, J.-L. (1996). ZLIB compressed data format specification version 3.3 (RFC 1950). Internet Engineering Task Force.https://www.rfc-editor.org/rfc/rfc1950


Deutsch, P. (1996). DEFLATE compressed data format specification version 1.3 (RFC 1951). Internet Engineering Task Force.https://www.rfc-editor.org/rfc/rfc1951


Seacord, R. C. (2013). Secure coding in C and C++ (2nd ed.). Addison-Wesley Professional.

OWASP Foundation. (2023). Uninitialized memory (Software weakness guidance).https://owasp.org

bottom of page