MongoDB memory disclosure risk - are exposed databases at risk?

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

View Full Forum →  |  NHI Foundation Course →