MongoDB MongoBleed CVE-2025-14847: Unauthenticated Memory Leak Under Active Exploitation

Can a database vulnerability expose uninitialized memory to an attacker without a password? Yes—and it’s happening right now to MongoDB instances worldwide. CVE-2025-14847, nicknamed MongoBleed, allows unauthenticated attackers to read sensitive heap memory from vulnerable MongoDB servers through a flawed compression handler. With 87,000+ exposed instances detected globally and active exploitation already underway, the U.S. CISA has mandated patches for Federal systems by January 19, 2026.

The root cause lies in MongoDB Server’s zlib message decompression logic (“message_compressor_zlib.cpp”). When processing compressed network packets, the code incorrectly returns the allocated buffer size instead of the actual decompressed data length. An attacker sends a malformed, undersized, or inconsistent zlib-compressed packet. The vulnerable code accepts it and returns adjacent heap memory beyond the legitimate decompressed output. This memory may contain fragments of the database state, credentials, API keys, or other uninitialized data sitting in process memory.

Affected versions span a wide range: MongoDB 8.2.0-8.2.2, 8.0.0-8.0.16, 7.0.0-7.0.26, 6.0.0-6.0.26, 5.0.0-5.0.31, 4.4.0-4.4.29, and all 4.2, 4.0, and 3.6 versions. Critically, zlib compression is the default configuration, meaning most unpatched deployments are vulnerable out-of-the-box. Patched versions released on December 19, 2025 include 8.2.3, 8.0.17, 7.0.28, 6.0.27, 5.0.32, and 4.4.30. MongoDB Atlas cloud deployments have been automatically patched.

This vulnerability demolishes a critical security assumption: that unauthenticated actors cannot access sensitive data. MongoDB defenders have historically relied on network segmentation and authentication enforcement. MongoBleed bypasses authentication entirely. An attacker only needs network access—no credentials, no complex exploitation chain, no user interaction required. Censys identified 87,000+ internet-exposed MongoDB instances; Wiz reported that 42% of cloud environments contain at least one vulnerable MongoDB instance (including internal, non-exposed resources).

The exposed heap memory is fragmentary but accumulative. An attacker sending hundreds of requests can reconstruct passwords, database connection strings, internal pointers, and session tokens. This information fuels follow-on attacks: lateral movement within cloud infrastructure, privilege escalation, or direct credential theft for wallet and account takeovers. The vulnerability pre-dates authentication, meaning an attacker never needs valid credentials to trigger it. For enterprises hosting sensitive data—healthcare records, financial transactions, authentication tokens—this represents acute operational risk.

Attack Mechanics: An attacker with network visibility to a MongoDB instance sends a specially crafted zlib-compressed message where the length field mismatches the actual payload. The decompression handler reads and returns more bytes than the legitimate message contains, leaking adjacent uninitialized heap memory to the attacker. Multiple requests can leak different memory regions, building a patchwork of sensitive data. No authentication or valid MongoDB credentials are needed.

Root Cause in Code: The vulnerable logic in “message_compressor_zlib.cpp” returns `output.length()` (allocated buffer size) instead of `decompressedSize` (actual decompressed bytes). When a malformed payload is smaller than the buffer, the function returns the full buffer contents, including garbage and sensitive adjacent memory.

Affected Deployment Patterns: MongoDB instances exposed directly to the internet, accessible via cloud security groups with overly permissive ingress rules, or internal instances reachable by a compromised application all qualify. The default zlib compression setting makes exposure automatic unless explicitly disabled at startup using the `–networkMessageCompressors` flag or configuration setting.

Remediation Paths: Immediate patching to fixed versions is the primary control. If patching cannot be deployed within 5–7 days, disable zlib compression by starting MongoDB with `mongod/mongos –networkMessageCompressors=snappy,zstd` (omitting zlib). Restrict network access via firewall rules or cloud security groups to application servers and administrative tools only. Monitor MongoDB logs for anomalous pre-authentication connections or unusual read patterns. Implement network intrusion detection signatures for malformed zlib packets destined to MongoDB ports.

MongoBleed joins a growing category of unauthenticated, pre-login memory-access vulnerabilities that expose fundamental assumptions in database security architecture. Its discovery aligns with the reality that database hardening now requires zero-trust positioning: assume the network is hostile and the instance is exposed. CISA’s addition of CVE-2025-14847 to its Known Exploited Vulnerabilities (KEV) catalog on December 29, 2025 signals active state-sponsored interest. Federal agencies must patch by January 19, 2026, a 21-day mandate reflecting the vulnerability’s severity and proof-of-concept availability.

MongoDB’s historical trust model—authentication on the wire, TLS optional—leaves pre-auth stages vulnerable. MongoBleed reveals that zlib decompression, a late-stage optimization step, was treated as a trusted operation. Security researchers at OX Security, Wiz, and QiAnXin independently verified the flaw and provided proof-of-concepts within days of disclosure. The coordinated disclosure prevented a prolonged zero-day window, but the lag between discovery (mid-December) and widespread patch deployment will extend the exploitation window through January and beyond.

Primary Sources: