CISA Adds MongoBleed to KEV as Exploitation Spreads to 87,000 Instances

CISA added MongoDB's memory disclosure vulnerability to its Known Exploited Vulnerabilities catalog on December 29, confirming what researchers had warned: CVE-2025-14847 is under active attack. Security firm Wiz reports that 42% of cloud environments contain at least one vulnerable MongoDB instance, with over 87,000 potentially exposed servers identified worldwide.

The vulnerability, now dubbed "MongoBleed" by researchers, allows unauthenticated attackers to read sensitive data directly from MongoDB server memory. That data often includes credentials, API keys, and cached query results—exactly what attackers need to escalate access.

How MongoBleed Works

The flaw exists in MongoDB's network message handling before authentication occurs. When the server receives compressed network messages, a bug in the zlib decompression logic mishandles length parameters. Sending malformed packets triggers the server to return uninitialized heap memory along with the expected response.

The attack requires no credentials. An attacker simply needs network access to the MongoDB port (default 27017) and the ability to send crafted packets. Low complexity, high impact.

Memory disclosure from database servers is particularly dangerous because that memory contains whatever the server was recently processing: connection strings to other systems, user passwords from authentication attempts, and fragments of query results. A patient attacker can harvest this data over time, building a picture of the environment without ever authenticating.

Federal Agencies Face January 19 Deadline

By adding CVE-2025-14847 to the KEV catalog, CISA has set a mandatory remediation deadline for Federal Civilian Executive Branch agencies. They must apply patches by January 19, 2026.

The KEV catalog serves as an authoritative list of vulnerabilities being exploited in the wild. While the compliance mandate only applies to federal agencies, CISA recommends all organizations treat KEV entries as high-priority patching targets.

MongoDB released patches in versions 8.2.3, 8.0.17, 7.0.28, 6.0.27, 5.0.32, and 4.4.30. Organizations running MongoDB Atlas received patches automatically.

Detection Tool Released

Security researchers have released MongoBleed Detector, an open-source tool for identifying potential exploitation attempts. The command-line utility analyzes MongoDB JSON logs to detect patterns consistent with the attack.

The tool operates offline, requiring no network access—important for environments where adding new network-connected security tools requires approval cycles. Security teams can run it against historical logs to determine if they were targeted before patching.

Detection focuses on:

• Malformed compression packets in connection logs
• Unusual memory allocation patterns
• Failed authentication sequences with suspicious timing

The detector provides a starting point, not a definitive answer. Sophisticated attackers may modify their approach to evade detection, but the tool catches known exploitation patterns.

Why 87,000 Instances?

MongoDB's popularity makes it an attractive target. The database powers applications across every industry, from startups to Fortune 500 companies. Many deployments—especially development and testing environments—get configured quickly and forgotten.

Cloud environments compound the exposure. Developers spin up database instances for temporary projects, and those instances sometimes remain accessible long after the project ends. Default configurations may expose the MongoDB port to broader network ranges than intended.

Wiz's 42% figure—the percentage of cloud environments with at least one vulnerable instance—reflects this reality. Organizations don't always know what they're running, let alone the patch status of every database instance.

What You Should Do Now

1. Inventory MongoDB deployments across your environment. Include development, staging, and shadow IT instances that may not appear in official asset lists.

2. Apply patches immediately for any instance running affected versions. If patching requires downtime coordination, implement network-level access controls in the interim.

3. Restrict network access to MongoDB ports. Production databases rarely need exposure beyond application servers. Use security groups, firewalls, or network policies to limit connectivity.

4. Check logs for exploitation attempts using the MongoBleed Detector or similar analysis. If you find evidence of exploitation, assume credential theft occurred and rotate secrets.

5. Review what credentials existed in memory on potentially compromised servers. Connection strings to other databases, API keys for external services, and user passwords should all be rotated if exposure is possible.

The Bigger Picture

MongoBleed follows a pattern security teams know well: a vulnerability disclosure is followed by rapid weaponization. The proof-of-concept exploit dropped days after patches became available, giving attackers a targeting list of organizations that move slowly.

The pre-authentication nature of this vulnerability makes it especially valuable for initial access. Attackers can probe exposed MongoDB instances without leaving authentication logs, harvest credentials, and use those credentials for lateral movement—all before defenders notice anything unusual.

Organizations that patched promptly after MongoDB's initial advisory likely avoided the worst. Those still running vulnerable versions should assume they're being probed and prioritize remediation accordingly.