Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

MongoDB CVE-2025-14847, informally called MongoBleed, is a remotely exploitable flaw that can let an unauthenticated client read uninitialized server heap memory when MongoDB handles certain Zlib-compressed protocol headers. Authorities reported active exploitation in late December 2025. That establishes reported attacks, not how many systems were compromised or whether exploitation is still ongoing. If you operate MongoDB, check the running version, upgrade to the fixed release for its branch, and investigate separately for signs of unauthorized access.

What is MongoBleed?

CVE-2025-14847 affects MongoDB Server’s handling of inconsistent length fields in Zlib-compressed network protocol headers. The National Vulnerability Database (NVD) describes a possible read of uninitialized heap memory by an unauthenticated remote client. Depending on what is present in memory, that could expose sensitive information. The documented impact is a confidentiality risk; the cited advisories do not establish that this flaw directly enables code execution or data modification. NVD vulnerability record.

MongoDB submitted a CVSS 4.0 score of 8.7 (High) and a CVSS 3.1 score of 7.5 (High) to NVD. These are MongoDB’s scores as the CVE Numbering Authority; NVD’s record says it had not supplied an independent assessment.

Is CVE-2025-14847 being exploited?

Yes: official authorities reported exploitation in the wild in late December 2025. On December 29, Australia’s Australian Cyber Security Centre (ACSC) said it was aware of “active global exploitation.” Canada’s December 29 alert cited open-source reporting of proof-of-concept exploits and in-the-wild exploitation, and NVD records that CISA added the CVE to its Known Exploited Vulnerabilities catalog on December 29, 2025. CISA’s catalog entry set a January 19, 2026 remediation deadline for federal civilian executive branch agencies. ACSC alert, Canadian alert, and NVD record.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

Those reports do not give a verified global count of compromised servers, prove that any particular exposed database was accessed, or establish that attacks remain active now. MongoDB separately said it had proactively patched tens of thousands of Atlas customers and hundreds of thousands of Atlas instances within days; those are the vendor’s patching figures, not counts of vulnerable or compromised deployments. In its December 29, 2025 statement, MongoDB said the flaw was not a breach or compromise of MongoDB, MongoDB Atlas, or its own systems. That statement concerns the vendor’s services and systems, not customer-managed servers. MongoDB’s security update.

Which MongoDB versions are affected?

NVD lists the versions below each fixed threshold as affected. Canada says MongoDB 4.2, 4.0, and 3.6 have no vendor fix and recommends upgrading to a fixed version. Check MongoDB’s current guidance and the exact branch you run before planning a change.

MongoDB Server branch Affected range Fixed threshold
8.2 Below 8.2.3 8.2.3
8.0 Below 8.0.17 8.0.17
7.0 Below 7.0.28 7.0.28
6.0 Below 6.0.27 6.0.27
5.0 Below 5.0.32 5.0.32
4.4 Below 4.4.30 4.4.30
4.2, 4.0, 3.6 All versions listed by NVD No vendor fix identified by Canada; upgrade to a fixed version

The Canadian alert has inconsistent ranges for 7.0 and 8.2 across its table and an earlier update. NVD’s affected range is below 7.0.28 and below 8.2.3; those are the safer thresholds to use alongside MongoDB’s current branch guidance. Sources: NVD, Canadian alert, and Canadian advisory update AV25-862.

How should you respond?

  1. Inventory your deployments. Identify MongoDB Server editions and the versions actually running across self-managed hosts and environments. Treat affected, internet-accessible instances as urgent to assess. For managed databases, check the provider’s status and version guidance rather than assuming the service is either affected or unaffected.
  2. Upgrade to a fixed release. Apply the fixed threshold for your branch, following MongoDB’s current instructions and your normal compatibility and change-control checks. If you are on 4.2, 4.0, or 3.6, plan migration to a fixed version because Canada identifies no vendor fix for those branches. Sources: MongoDB and Canada.
  3. Reduce exposure while a patch is pending. Official guidance recommends omitting zlib from MongoDB’s network-message compression configuration. Singapore and Canada mention snappy or zstd as alternatives; validate application compatibility and follow vendor procedures before changing the setting. Canada also recommends restricting access to trusted IP addresses and avoiding direct internet exposure. These measures reduce risk while you patch; they do not repair the vulnerable software. Sources: Singapore CSA and Canada.
  4. Investigate possible access. Review MongoDB logs and connection telemetry for anomalous pre-authentication connections or unexpected errors. Follow your incident-response process if you find suspicious activity. A vulnerable version or internet exposure alone does not prove an attacker accessed the server or took data. Sources: Canada and ACSC.
  5. Escalate when warranted. Organizations can use Canada’s My Cyber Portal or email reporting channel, or contact Australia’s ACSC Cyber Security Hotline for advice if impacted. Use the reporting route relevant to your location and incident-response obligations. Sources: Canada and ACSC.

Can MongoBleed expose passwords or secrets?

The flaw can expose uninitialized heap memory, so sensitive information present in server memory could potentially be disclosed. The cited sources do not establish that a particular password, key, or secret was exposed in every attack—or that every vulnerable server was accessed. If you find evidence of suspicious access, assess what the affected process could have held in memory and handle credential or secret rotation through your incident-response process.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Support on Ko-Fi

What MongoDB says about its response

MongoDB says its Security Engineering team identified the vulnerability on December 12, 2025, validated it and developed a fix over December 12–14, and began patching its Atlas fleet on December 15. The company says it had patched the majority of the fleet by December 17 and the remainder by December 18, published the CVE on December 19, and issued community guidance on December 23. This is the vendor’s account of its own response, not evidence about the status of self-managed customer deployments. MongoDB security update, December 29, 2025.

Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.