New MongoDB Vulnerability Allows Attackers to Crash Servers, Exposing Critical Data

Cato CTRL’s senior security researcher, Vitaly Simonovich, has uncovered a high-severity dos vulnerability in MongoDB, tracked as CVE-2026-25611, that lets unauthenticated attackers crash any exposed MongoDB server.​

CVE-2026-25611 is rooted in MongoDB’s OP_COMPRESSED wire protocol, a compression feature introduced in version 3.4 and enabled by default since version 3.6.

The flaw is classified under CWE-405 (Asymmetric Resource Consumption), carrying a CVSS 4.0 score of 8.7 and a CVSS 3.1 score of 7.5 (High).

It affects all MongoDB deployments with compression enabled, including MongoDB Atlas, across versions 7.0, 8.0, and 8.2 prior to their respective patches.

How the Attack Works

When MongoDB receives a compressed message, it reads the uncompressedSize field from the packet header and immediately allocates a memory buffer of that size, before verifying whether the actual compressed data matches the claimed size.

An attacker exploits this by sending a crafted ~47KB packet while falsely declaring an uncompressedSize of 48MB, tricking the server into reserving a massive memory block with almost no real data.​

This creates a staggering 1,027:1 amplification ratio, think of sending the equivalent of a short email, but forcing the server to reserve memory the size of an audio podcast episode.

The vulnerable function SharedBuffer::allocate(uncompressedSize) in message_compressor_manager.cpp allocates memory at line 158, while validation only happens at line 175, well after the damage is done.​

No credentials are required. The exploit targets MongoDB’s wire protocol parsing before any authentication check, making every internet-facing MongoDB instance a potential victim.

The attack scales with the target’s RAM and requires only concurrent TCP connections to port 27017.

A 512MB MongoDB instance crashes with just 10 connections sending roughly 457KB of traffic, while a 64GB enterprise server falls with around 1,363 connections and only 64MB of data, well within the capability of a single home internet connection.

According to Catonetworks, more than 207,000 MongoDB instances are currently exposed to the internet.

Indicators of Compromise

Security teams should watch for the following warning signs:

• High volume of TCP connections to port 27017 from a single source IP
• OP_COMPRESSED packets (opCode 2012) with uncompressedSize exceeding 10MB but total packet size under 100KB
• Rapid memory spike in the mongod process
• OOM (out-of-memory) killer events in system logs targeting MongoDB
• MongoDB process exiting with code 137 (kernel SIGKILL due to OOM)

Patch and Mitigation

MongoDB has released fixes in versions 7.0.29, 8.0.18, and 8.2.4, which validate the uncompressedSize field before any memory allocation.

Organizations should upgrade immediately and avoid exposing port 27017 to 0.0.0.0/0. MongoDB Atlas users should restrict access via IP access lists and use private connectivity instead of allowing open access.

Configuring OS-level memory limits using cgroups on Linux can also reduce blast radius until patching is complete.

This vulnerability was responsibly disclosed to MongoDB through its bug bounty program and patched in collaboration with MongoDB’s security team.

Follow us on Google News, LinkedIn, and X to Get Instant Updates and Set GBH as a Preferred Source in Google.

​