MongoBleed (CVE-2025-14847): How to identify and fix vulnerable assets

Dec 29, 20253 min

Last update: 8:00 AM CT, Dec. 28, 2025

TL;DR: A critical unauthenticated memory leak vulnerability, CVE-2025-14847 (aka "MongoBleed"), with a CVSS score of 8.7 and confirmed active exploitation, allows remote attackers to exfiltrate sensitive data (including PII, passwords, and keys) from MongoDB's heap memory. This post provides steps to identify and remediate affected assets.

Summary

On December 19, 2025, a high-severity vulnerability (CVE-2025-14847) affecting MongoDB Server's zlib network message compression logic was disclosed. The vulnerability allows unauthenticated remote attackers to access MongoDB's heap memory (with access to critical data including plaintext database passwords, session tokens, and secret keys) by manipulating the expected message length of a database response, similarly to Heartbleed (aka "MongoBleed").

The vulnerability:

Has a CVSS base score of 8.7 (Critical),
Has a public proof of concept and confirmed active exploitation.
Presents critical risk especially for organizations running self-managed MongoDB instances.

A video by Ed (from Low Level) provides further details about this vulnerability in a comprehensive format.

Affected/Not affected systems

As of Dec. 28, 2025, 8:00 AM CT.

Systems affected: Self-managed MongoDB instances with zlib compression enabled (default) in the following versions:

MongoDB 8.2.0 through 8.2.3
MongoDB 8.0.0 through 8.0.16
MongoDB 7.0.0 through 7.0.26
MongoDB 6.0.0 through 6.0.26
MongoDB 5.0.0 through 5.0.31
MongoDB 4.4.0 through 4.4.29
All MongoDB Server v4.2 versions
All MongoDB Server v4.0 versions
All MongoDB Server v3.6 versions

Systems not affected:

MongoDB Atlas instances (already patched by MongoDB)
Versions patched to the fixed versions (more on the Remediation section).

Identifying affected assets with Axonius

The Axonius queries below will help you identify vulnerable MongoDB instances across your infrastructure. Before you begin, perform a global discovery to ensure your asset data is current.

1. Identify vulnerable MongoDB instances detected by your vulnerability scanners

To find instances of the CVE-2025-14847 already identified by your vulnerability scanners, go to Assets > Vulnerabilities and search for:

{"vulnerabilities":"(\"specific_data.data.cve_id\" == \"CVE-2025-14847\")","devices":""}

2. Identify vulnerable MongoDB versions NOT found by your scanners

To reduce the mean time to detection (MTTD) or deployment gaps from vulnerability scanners, go to Assets > Software and then search for all MongoDB managed instances not patched for mongobleed:

{"software":"((\"specific_data.data.installed_software.name\" == regex(\"mongodb\", \"i\")) and not (\"specific_data.data.installed_software.name\" == regex(\"compass\", \"i\"))) and not (\"specific_data.data.installed_software.version\" in [\"4.4.29\",\"5.0.31\",\"6.0.26\",\"7.0.26\",\"8.0.16\",\"8.2.3\"])","devices":""}

3. Find vulnerable MongoDB instances exposed to the Internet

To prioritize your work on vulnerable MongoDB instances exposed to the internet, narrow down the search for MongoDB to hosting devices with internet exposure:

{"software":"((\"specific_data.data.installed_software.name\" == regex(\"mongodb\", \"i\")) and not (\"specific_data.data.installed_software.name\" == regex(\"compass\", \"i\"))) and not (\"specific_data.data.installed_software.version\" in [\"4.4.29\",\"5.0.31\",\"6.0.26\",\"7.0.26\",\"8.0.16\",\"8.2.3\"])","devices":"((\"specific_data.data.internet_exposure\" == ({\"$exists\":true,\"$ne\":\"\"})))"}

Tips:

Axonius calculates the Internet Exposures field automatically based on the configuration of your network and firewall equipment. The discovery works across on-prem (i.e. Cisco, Palo Alto, Fortinet) and cloud (Cloudflare, AWS, Azure, ZScaler) networks, ensuring visibility regardless of plane.
You can apply the same principle used in this query to prioritize your work based on other signals of risk (i.e. MongoDB in EC2 instances with tag PCI-DSS or Production Subnet in AWS, MongoDB in devices with git cli installed, MongoDB in devices missing endpoint protection)

3. Identify MongoDB instances already updated

This software query identifies MongoDB Servers already updated to address mongobleed:

{"software":"((\"specific_data.data.installed_software.name\" == regex(\"mongodb\", \"i\")) and not (\"specific_data.data.installed_software.name\" == regex(\"compass\", \"i\"))) and (\"specific_data.data.installed_software.version\" in [\"4.4.29\",\"5.0.31\",\"6.0.26\",\"7.0.26\",\"8.0.16\",\"8.2.3\"])","devices":""}

Remediation and Mitigation

For updates, visit the MongoDB security advisory

MongoDB has released security updates for MongoDB versions 4.4.0 and above, alongside workaround guidance.

Remediation

MongoDB 4.4.0 and above: patch to the respective latest MongoDB version (8.2.3, 8.0.17, 7.0.28, 6.0.27, 5.0.32, or 4.4.30)
MongoDB v3.6, v4.0, and v4.2: These versions are no longer supported by MongoDB.

Mitigation

If immediate patching is not possible, disable zlib compression or use an alternative compression library (such as snappy or zstd) by explicitly omitting it from networkMessageCompressors or net.compression.compressors.
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 (v3.6, v4.0, v4.2), as they remain permanently vulnerable.
Credential Rotation: Because MongoBleed exfiltrates data from memory, assume any secrets (passwords, AWS keys) present in the server's memory are compromised. Rotate these secrets immediately after patching.