CVE-2025-14847

MongoDB can accept compressed “network messages” from clients. This bug gets confused about a length value inside those compressed messages, which can cause the server to accidentally expose pieces of its own memory. Think of it like a mailroom that sometimes reads the wrong number of pages from a letter folder and accidentally shows a bit of what was inside the folder instead of the letter.

This matters if you run mongodb (including deployments on Red OS or Mailion variants that include mongodb) and it listens for network connections from other machines. The flaw does not require a login or user interaction, so an attacker just needs network access to reach the service. Because it’s reachable over the network and requires no authentication, prioritize exposure to the internet or any untrusted network paths (only safe if the service is not reachable from outside).

This is RED because CISA has it in its Known Exploited Vulnerabilities list, which means it’s treated as actively relevant and should be remediated on a strict timeline. The vulnerability allows an unauthenticated remote client to read memory, so attackers don’t need stolen credentials to start testing.

1. Confirm product + version in use

   • From your MongoDB server logs/management UI/command-line output, capture the exact mongodb version string.
   • If you run Red OS or Mailion, confirm whether they include mongodb and what mongodb version they ship.

2. Determine if your version is affected

   • Affected ranges (from the published issue behavior):
     • 4.4 prior to 4.4.30
     • 5.0 prior to 5.0.32
     • 6.0 prior to 6.0.27
     • 7.0 prior to 7.0.28
     • 8.0 prior to 8.0.17
     • 8.2 prior to 8.2.3
   • If your version is earlier than the fixed releases below, you should treat your deployment as exposed.

3. Upgrade to the fixed version

   • Choose the matching fixed target for your major/minor line:
     • mongodb fixed in 4.4.30
     • mongodb fixed in 5.0.32
     • mongodb fixed in 6.0.27
     • mongodb fixed in 7.0.28
     • mongodb fixed in 8.0.17
     • mongodb fixed in 8.2.3
   • Plan for a normal MongoDB upgrade procedure for your environment (staging first if you have one).
   • Note: the findings only provide fixed versions, not special compatibility guidance—follow the MongoDB upgrade notes for your upgrade path.

4. If you cannot upgrade immediately (temporary risk reduction)

   • Apply mitigations per the vendor’s instructions linked from the MongoDB security advisory entry (referenced as SERVER-115508).
   • If mitigations are not available or practical for your setup, CISA guidance indicates discontinuing use of the product if mitigations cannot be applied.

5. Validate the change

   • After upgrading, re-check the MongoDB version string.
   • Confirm the service is still reachable from intended client networks only.

6. Monitor for ongoing exposure

   • Look for abnormal network traffic patterns targeting MongoDB’s protocol handling from unexpected client IPs.
   • Ensure firewall/security group rules restrict access to known application hosts and do not expose the database broadly.

CISA timeline

• CISA remediation due date for this KEV entry: 2026-01-19.

Severity/issue: High (CVSS 7.5) memory disclosure risk. The weakness is categorized as CWE-130 (Improper Handling of Length Parameter). Mechanism: MongoDB’s handling of Zlib-compressed protocol headers can be confused by mismatched header length fields, causing the server to read uninitialized heap memory. Reachability: Network-based, without authentication or user interaction per the findings.

Exploitation status: The issue is listed in CISA KEV (added 2025-12-29) with a remediation due date of 2026-01-19, and a public exploit is available. That combination indicates it should be treated as actively relevant even if specific dated press reports are not present in the provided articles.

Patching: Fixed in MongoDB versions 4.4.30, 5.0.32, 6.0.27, 7.0.28, 8.0.17, and 8.2.3 as captured in the findings.

EPSS: A prediction score is included in the findings, but due to KEV listing and public exploit availability, remediation should be driven by confirmed-exploitation indicators rather than the prediction figure.