MongoDB has disclosed a high-severity unauthenticated information leak vulnerability, tracked as CVE-2025-14847 and dubbed MongoBleed (after HeartBleed), affecting multiple supported and legacy MongoDB Server versions. The flaw can be exploited remotely by unauthenticated attackers with low complexity, potentially leading to exfiltration of sensitive data and credentials.
Self-hosted MongoDB instances remain at risk until patched, whereas MongoDB Atlas instances have been upgraded automatically and no customer action is required.
How do I know if I'm affected?
To determine if your specific MongoDB environment is vulnerable to CVE-2025-14847, follow the triage logic below. This flowchart guides you through the necessary checks regarding deployment type, server version, and the critical zlib compression configuration:
What is CVE-2025-14847?
CVE-2025-14847 stems from a flaw in MongoDB Server’s zlib-based network message decompression logic, which is processed prior to authentication. By sending malformed, compressed network packets, an unauthenticated attacker can trigger the server to mishandle decompressed message lengths, resulting in uninitialized heap memory being returned to the client. This allows attackers to remotely leak fragments of sensitive in-memory data without valid credentials or user interaction.
At a code level, the vulnerability was caused by incorrect length handling in message_compressor_zlib.cpp. The affected logic returned the allocated buffer size (output.length()) instead of the actual decompressed data length, allowing undersized or malformed payloads to expose adjacent heap memory.
Because the vulnerability is reachable prior to authentication and does not require user interaction, Internet-exposed MongoDB servers are particularly at risk.
Wiz Research data: what’s the risk to cloud environments?
Based on Wiz data, 42% of cloud environments have at least one instance of MongoDB in a version vulnerable to CVE-2025-14847, including both publicly exposed and internal resources. Wiz has been able to validate many internet-facing instances as exploitable.
Censys has reported observing 87K potentially vulnerable instances worldwide.
What sort of exploitation has been identified in the wild?
A working exploit has been publicly available since December 26, 2025, with initial reporting of exploitation in the wild reported shortly after, and the vulnerability has since been added to CISA KEV.
Which products are affected?
The vulnerability impacts MongoDB in versions 8.2.0 through 8.2.2, 8.0.0 through 8.0.16, 7.0.0 through 7.0.27, 6.0.0 through 6.0.26, 5.0.0 through 5.0.31, 4.4.0 through 4.4.29, and all MongoDB Server v4.2, v4.0, and v3.6 versions.
Note that Ubuntu originally stated that the same vulnerability affected multiple unrelated Ubuntu packages such as rsync due to their use of zlib, but this was later retracted.
Which actions should security teams take?
Upgrade immediately to one of the patched versions: 8.2.3, 8.0.17, 7.0.28, 6.0.27, 5.0.32, or 4.4.30.
If immediate patching is not possible, disable
zlibcompression by explicitly omitting it fromnetworkMessageCompressorsornet.compression.compressors. Safe alternatives includesnappy,zstd, or fully disabling compression.Restrict network exposure of MongoDB servers (e.g., firewall rules, private networking).
Monitor MongoDB logs for anomalous pre-authentication connections or unexpected crashes (see this blogpost from Eric Capuano for additional detection guidance, and this detection tool from Florian Roth).
Plan upgrades for any remaining end-of-life MongoDB versions, as they remain permanently vulnerable.
How can wiz help?
Wiz customers can use the pre-built query and advisory in the Wiz Threat Center to search for vulnerable instances in their environment.
Update (December 31, 2025)
To assist security teams in validating exploitability, Wiz Research has published a custom Nuclei template (see below) designed to deterministically and safely detect if a MongoDB server is vulnerable to CVE-2025-14847, without exfiltrating data. This template validates the vulnerability by sending a single crafted packet that triggers the specific memory leak condition. It then analyzes the server's response for leaked BSON signatures, confirming the flaw exists without requiring authentication.
Nuclei Template
id: CVE-2025-14847
info:
name: CVE-2025-14847 - Information Disclosure allowed in MongoDB Server
author: Wiz Research
severity: High
description: |
Mismatched length fields in Zlib compressed protocol headers may allow a read of uninitialized heap memory by an unauthenticated client in MongoDB.
metadata:
max-request: 1
tags: mongodb,memory-leak,network
tcp:
- host:
- "{{Hostname}}"
inputs:
- data: "2a0000000100000000000000dc070000dd0700003200000002789c636080028144064620050002ca0073"
type: hex
read-size: 1024
matchers:
- type: dsl
dsl:
- "contains(toupper(zlib_decode(substr(data, 25))), 'BSON')"
- "contains(toupper(data), 'BSON')"
condition: orHow this detection method helps defenders
While the original proof-of-concept exploit published by Joe Desimone is effective at demonstrating critical impact by aggressively harvesting data from the server's memory, this Nuclei template is engineered specifically for safe and simple exploitability validation. Real-world attacks observed in the wild often flood the server with thousands of connections to scrape large amounts of RAM. In contrast, this template sends a single, specially crafted packet. It is a low-intensity check that confirms the vulnerability by detecting the presence of a BSON signature in the unauthorized memory space, rather than actually parsing sensitive customer data.
How it works - the "magic" packet
The vulnerability acts as a buffer over-read caused by a trust issue in the MongoDB Zlib decompression logic. The flaw allows an attacker to arbitrarily dictate the size of the memory buffer the server allocates, regardless of how much data is actually provided in the compressed payload. The Hex payload used in this template exploits this by wrapping a valid, minimal BSON document, specifically {"a": 1}, inside a malformed OP_COMPRESSED message. The header of this message (specifically the uncompressedSize field) is set by the attacker to lie to the server, claiming the data will expand to a size significantly larger than what the tiny {"a": 1} payload actually requires.
When the server processes this packet, it trusts the header and allocates a large heap buffer based on the attacker's fake size. This buffer initially contains uninitialized "dirty" memory from previous operations. The decompression process writes the small {"a": 1} payload into the start of the buffer but leaves the rest of the space untouched. Because of the vulnerability, the server attempts to parse this entire buffer as BSON. It successfully reads the first valid document, but then continues reading the "dirty" memory as if it were part of the data stream.
Since this uninitialized memory is almost never valid BSON, the parser inevitably fails. Crucially, the resulting error message often quotes the "invalid" bytes it encountered, potentially leaking sensitive data back to the client. This mechanism explains why actual exploitation is a "game of chance" requiring multiple requests: the attacker is betting that the unallocated memory contains valuable data and that the specific way the parser fails will reveal it as a printable string. Our Nuclei template, however, bypasses this need for luck by inspecting the raw stream for BSON markers in the response, deterministically confirming the leak exists without needing to successfully extract readable secrets.
