New MongoDB vulnerability lets attackers crash exposed servers with tiny requests
4 min. read 
Published on
A newly documented MongoDB denial-of-service flaw, CVE-2026-25611, can let an unauthenticated attacker exhaust server memory and crash a MongoDB instance by sending specially crafted messages over the network. The NVD description states that crafted unauthenticated messages can exhaust available memory and crash MongoDB.
MongoDB has already shipped fixes across supported release trains. MongoDB’s release notes confirm that MongoDB 8.2.4, 8.0.18, and 7.0.29 include a fix for CVE-2026-25611.
Security researchers at Cato CTRL explain the practical abuse case: an attacker can trigger large memory allocations by abusing the compression path in MongoDB’s wire protocol, then repeat that across multiple connections until the instance hits out-of-memory conditions. Cato also says Shodan data suggests a very large number of MongoDB servers remain reachable from the public internet.
This is a pure availability issue. NVD lists impact as availability loss, with no direct confidentiality or integrity impact in the scoring vector. Still, downtime for a database can quickly become an outage for everything that depends on it.
What CVE-2026-25611 is
NVD describes CVE-2026-25611 as asymmetric resource consumption (CWE-405), where small attacker input can force high resource usage on the server, leading to a crash.
Cato CTRL ties the issue to MongoDB’s compressed message handling (OP_COMPRESSED) and says the server allocates memory based on an attacker-controlled “uncompressed size” field before it fully validates the decompressed result.
Fixed versions
MongoDB lists CVE-2026-25611 as fixed in these releases:
| MongoDB release train | Version that includes the fix | Source |
|---|---|---|
| 8.2 | 8.2.4 | MongoDB release notes |
| 8.0 | 8.0.18 | MongoDB release notes |
| 7.0 | 7.0.29 | MongoDB release notes |
MongoDB also links the underlying engineering work from the CVE record to server-side issues that tightened compressor handling and capped network-buffer memory allocation.
How the attack works in practice
| Step | What happens | Why it hurts |
|---|---|---|
| 1 | Attacker sends crafted compressed messages to a MongoDB endpoint | Input stays small while claimed “uncompressed” size stays large |
| 2 | Server allocates memory based on attacker-controlled sizing | Memory consumption grows per connection |
| 3 | Attacker repeats across many concurrent connections | Server hits RAM pressure and may crash or get OOM-killed |
What defenders should do now
- Patch first
- Upgrade to 8.2.4, 8.0.18, or 7.0.29 based on your train.
- Remove public exposure
- Do not leave MongoDB listening on the public internet. Even without this bug, exposed databases remain a common target.
- If you must support remote access, put MongoDB behind a VPN or a private access layer and restrict source IPs.
- Disable compression as a stopgap
- Cato CTRL says you can disable network message compression using
--networkMessageCompressors=disabledif you cannot upgrade immediately.
- Cato CTRL says you can disable network message compression using
- Apply connection guardrails
- Cato recommends tightening connection limits (for example,
maxIncomingConnections) and watching for bursts of connections to port 27017.
- Cato recommends tightening connection limits (for example,
Detection and monitoring signals
| Signal | What to watch for |
|---|---|
| Connection behavior | Sudden spikes in new TCP connections to 27017, especially many short-lived or idle sessions |
| Packet pattern | Very small compressed packets paired with unusually large claimed uncompressed sizes (researchers highlight this as a key signature) |
| Host telemetry | Rapid MongoDB memory growth, kernel OOM activity targeting mongod, and service restarts |
FAQ
NVD describes it as a bug where crafted unauthenticated messages can exhaust memory and crash a MongoDB server.
Yes. NVD’s CVSS vector lists network attack with no privileges required and availability impact.
MongoDB release notes confirm fixes in 8.2.4, 8.0.18, and 7.0.29.
Cato CTRL says the issue affects deployments with compression enabled, including Atlas, depending on configuration and exposure. Treat this as relevant for any environment that exposes MongoDB endpoints and confirm your patch status through your provider tooling.
Disable network message compression and block public access to MongoDB while you schedule an upgrade.
Read our disclosure page to find out how can you help VPNCentral sustain the editorial team Read more
Improve this guide
User forum
0 messages