MongoBleed (CVE-2025-14847) exploited in the wild: everything you need to know

Detect and mitigate CVE-2025-14847, an unauthenticated information leak vulnerability in MongoDB. Exploitation has been observed in the wild. Organizations should patch urgently.

MongoDB has disclosed a high-severity unauthenticated information leak vulnerability, tracked as CVE-2025-14847 and dubbed MongoBleed (afterHeartBleed), 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 beenupgraded automaticallyand no customer action is required.

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 criticalzlibcompression configuration:

CVE-2025-14847stems from a flaw in MongoDB Server’szlib-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 inmessage_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.

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 hasreportedobserving 87K potentially vulnerable instances worldwide.

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 beenaddedto CISA KEV.

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 asrsyncdue to their use ofzlib, but this was laterretracted.

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, disablezlibcompression 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 (seethis blogpostfrom Eric Capuano for additional detection guidance, andthis detection toolfrom Florian Roth).

Plan upgrades for any remaining end-of-life MongoDB versions, as they remain permanently vulnerable.

Wiz customers can use the pre-built query and advisory in theWiz Threat Centerto search for vulnerable instances in their environment.

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.

While the original proof-of-concept exploit published byJoe Desimoneis 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.

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 malformedOP_COMPRESSEDmessage. The header of this message (specifically theuncompressedSizefield) 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.

MongoDB advisory

Ubuntu advisory

POC exploit from Joe Desimone of Elastic Security

Kevin Beaumont blogpost

Eric Capuano blogpost

Ox Security blogpost

How the Kenna sunset is giving security leaders the opportunity to outgrow vulnerability silos and adopt a unified exposure management model.

How Wiz AI-SPM delivers a complete view of exposed AI application endpoints — from Vibe Coding to MCP — and why that visibility matters.

Unified visibility into OCI identities, permissions, and policies — mapped into Wiz’s Security Graph.

Get a personalized demo

©2026Wiz, Inc.

StatusPrivacy PolicyTerms of UseModern Slavery StatementCookie Settings