MongoDB, one of the world’s most widely used NoSQL databases, stores and manages structured, semi-structured, and unstructured data using JSON-like documents organized within collections. This approach differs significantly from traditional relational databases, which rely on table-based structures.
Security researchers have now identified a high-severity vulnerability, tracked as CVE-2026-25611 (CVSS score: 7.5), that could allow unauthenticated attackers to exploit vulnerable MongoDB deployments with minimal bandwidth.
The flaw is essentially a memory disclosure vulnerability that enables attackers to remotely extract sensitive information from a server’s memory. Some early reports on social media claimed the issue could allow attackers to “crash any server,” but security experts say the primary risk is the ability to “bleed” sensitive memory data from affected systems, which could expose confidential information.
According to researchers at Cato Networks’ threat intelligence unit, Cato CTRL, the vulnerability affects both MongoDB Atlas and self-hosted MongoDB deployments where compression is enabled. The issue impacts MongoDB version 3.4 and later, with compression enabled by default beginning in version 3.6.
The vulnerability specifically lies in MongoDB’s OP_COMPRESSED wire protocol, a mechanism designed to reduce bandwidth usage by compressing data exchanged between the database server and clients.
Internet-wide scanning data from Shodan suggests the exposure could be significant, with more than 207,000 MongoDB instances currently accessible online and potentially vulnerable.
Before confirming the true decompressed size, the server allocates RAM depending on the attacker-controlled uncompressedSize number when it gets a compressed message, according to Cato CTRL.
An attacker can claim an uncompressed size of 48MB while sending a tiny 47KB zlib-compressed packet.
SentinelOne observes that the server arbitrarily allots by setting aside 48MB for each connection, leading to an enormous 1,027:1 memory amplification ratio.
The attacker rapidly depletes the server’s RAM by establishing numerous concurrent connections, which results in an Out-of-Memory (OOM) kernel killing the exit code 137.
This denial-of-service attack is an extremely effective measure, as a 512MB server breaks in about two seconds with just ten clients transferring 457KB of data, according to Cato CTRL’s testing.
In a timespace of three seconds, a 1GB instance drops to 25 connections. With about 1,363 connections and only 64MB of traffic from a typical residential internet connection, even a large 64GB enterprise database can be put down in less than a minute.
It is advised that network defenders should keep an eye out for quick connection formation that stays idle without use and for large numbers of TCP connections to port 27017 from a single source.
OP_COMPRESSED packets claiming an uncompressed size of more than 10MB are smaller than 100KB. Rapid MongoDB memory spikes and OOM killer events that target the mongod process in system logs are examples of system indicators.
Administrators should update to the patched MongoDB versions 8.2.4, 8.0.18, or 7.0.29 right away in order to lessen this hazard.
Nearly all of the MongoDB Server versions published throughout the past eight years are those that are affected by the vulnerability, aside from 8.2.4, 8.0.18 or 7.0.29. Other affected MongoDB versions are
MongoDB 8.2: Previous iterations before 8.2.3
MongoDB 8.0: Before 8.0.17 versions
MongoDB 7.0: Before 7.0.28 versions
MongoDB 6.0: Before 6.0.27 versions
MongoDB 5.0: Versions earlier than 5.0.32
MongoDB 4.4: Before 4.4.30 versions
Legacy Versions: Patches for all 4.2.x, 4.0.x, and 3.6.x versions are typically not available due to their vulnerability.
Cato CTRL suggests using it –networkMessageCompressors=disabled to completely deactivate compression if upgrading is not feasible right away or not able to patch it. This method is the disabled zlib compression method.
Other ways to protect the servers are to update to a fixed version right away, like versions 8.2.3, 8.0.17, 7.0.28, etc. Automatic patches have already been applied to MongoDB Atlas-controlled instances.
Also limit network access to make sure that only trusted IP addresses may access your MongoDB port, which is by default 27017.
By rotating credentials, it is assumed that the memory contents may have leaked if your server was accessible to the internet. Rotate all session secrets, database passwords, and API keys.
Additionally, companies must use firewalls to limit database network access to trustworthy networks, use maxIncomingConnections to set connection limitations, and refrain from permitting public network access (0.0.0.0/0) on MongoDB Atlas clusters.
We use cookies to ensure that we give you the best experience on our website. If you continue to use this site we will assume that you are happy with it.
