Notifications
Clear all
Topic starter
11/06/2026 10:44 pm
TL;DR: CVE-2025-14847 affects MongoDB Server across multiple supported and legacy versions, where malformed zlib-compressed requests can return uninitialized heap memory without authentication and with low exploitation complexity, according to Orca Security. The flaw turns reachable databases into data-exposure targets, so patching and exposure reduction now matter more than CVSS alone.
NHIMG editorial — based on content published by Orca Security: CVE-2025-14847 and MongoDB Server memory disclosure risk
By the numbers:
- CVE-2025-14847 carries a CVSS score of 7.5/8.7 and affects MongoDB Server versions 8.2.0 through 8.2.3, 8.0.0 through 8.0.16, 7.0.0 through 7.0.26, 6.0.0 through 6.0.26, 5.0.0 through 5.0.31, 4.4.0 through 4.4.29, and all 4.2, 4.0, and 3.6 series builds.
- When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes.
Questions worth separating out
Q: What breaks when unauthenticated database memory disclosure is possible?
A: When a database can return uninitialized memory without authentication, the normal identity boundary no longer protects the data that the service has already loaded.
Q: Why do exposed database services increase the impact of memory disclosure bugs?
A: Because reachability determines whether an attacker can exploit the flaw at scale.
Q: How do security teams know whether compression-related exposure is actually under control?
A: They need evidence that all affected instances are on fixed versions, that risky protocol features are disabled only as temporary containment, and that no reachable database remains outside the normal patch process.
Practitioner guidance
- Inventory every reachable MongoDB instance Map each server version, network path, and exposure point before deciding remediation order.
- Patch to a fixed MongoDB release immediately Move affected servers to the vendor-fixed versions, including 8.2.3, 8.0.17, 7.0.28, 6.0.27, 5.0.32, or 4.4.30, and treat older unsupported series as urgent upgrade candidates.
- Disable zlib compression only as a short-lived containment step Use feature reduction only when patching cannot happen immediately, then restore a supported compression setting once the vulnerable version has been removed.
What's in the full analysis
Orca Security's full analysis covers the operational detail this post intentionally leaves for the source:
- Affected version ranges and fixed releases for each MongoDB Server branch
- Exposure context used by the vendor to prioritise remediation, including internet reachability and asset criticality
- Platform workflow details for identifying vulnerable assets in the Orca Cloud Security Platform
- The vendor's newItem view and remediation prioritisation workflow for exposed instances
👉 Read Orca Security's analysis of CVE-2025-14847 and MongoDB exposure risk →
MongoDB memory disclosure risk - are exposed databases at risk?
Explore further
12/06/2026 7:02 am
Unauthenticated memory disclosure is a data governance failure, not just a vulnerability class. This issue bypasses the usual identity checkpoint entirely because the attacker does not need a valid session or account to obtain sensitive output. The important shift for practitioners is that database reachability and memory residency now belong in the same risk conversation as patch hygiene and secrets handling. The implication is that identity and infrastructure teams must treat data exposure paths as part of the control plane, not only the application layer.
A few things that frame the scale:
- Lack of credential rotation is cited as the top cause of NHI-related attacks by 45% of organisations, followed by inadequate monitoring and logging (37%) and over-privileged accounts (37%), according to The State of Non-Human Identity Security.
- Another finding from our research shows that 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, which leaves adjacent access paths harder to govern.
A question worth separating out:
Q: Who is accountable when a vulnerable database leaks sensitive memory?
A: Accountability sits with both the service owner and the team responsible for exposure management. If an externally reachable database remains unpatched, the failure is operational as well as technical. Governance frameworks should require clear ownership for version state, network exposure, and emergency mitigation so that disclosure risk cannot sit in a blind spot.
👉 Read our full editorial: MongoDB memory disclosure risk exposes unauthenticated data leakage
