What happened
A new high‑severity vulnerability in MongoDB, tracked as CVE‑2025‑14847 and nicknamed MongoBleed, is being actively exploited by threat actors to leak sensitive data from database memory without authentication. The flaw arises from how MongoDB handles zlib compressed network messages, allowing attackers to send crafted requests and receive uninitialized heap memory back, potentially exposing session tokens, passwords, API keys and other sensitive information. Exploitation began shortly after proof‑of‑concept details and exploit code were published.
Who is affected
Self‑hosted MongoDB instances across a wide range of versions (including 8.2.x, 8.0.x, 7.0.x, 6.0.x, 5.0.x and 4.4.x prior to their patched releases) are impacted. Internet‑exposed servers are particularly at risk because the flaw is reachable before authentication. Scanning by internet measurement platforms indicates tens of thousands of potentially vulnerable instances worldwide.
Why CISOs should care
- Unauthenticated data exposure: Attackers do not need valid credentials to exploit the flaw, significantly lowering the bar for abuse.
- Sensitive information leakage: Memory leaks can reveal critical secrets such as credentials, tokens or configuration data that can enable further compromise.
- Widespread exposure: A large population of self‑managed MongoDB servers, many internet‑accessible, remains unpatched, increasing the likelihood of mass exploitation.
3 practical actions
- Patch immediately: Ensure all self‑hosted MongoDB servers are updated to the patched versions.
- Disable zlib compression: Where updates can’t be applied quickly, disable zlib compression to mitigate exploitation risk.
- Hunt for signs of exploitation: Review access logs and unusual query patterns for indications of unauthorized probing or memory leak activity.