MongoDB has fixed a critical memory-safety flaw in the replication engine of its database server that can be triggered by requests requiring no authentication. Tracked as CVE-2026-118383, it can crash the server process and, according to MongoDB, "under certain conditions" allow arbitrary code execution in the context of the server.
The flaw matters because it sits in replica sets, the clustered configuration that most production MongoDB deployments use for redundancy. MongoDB's record says replica set members are affected, including the shard and config server replica set members of sharded clusters. Standalone mongod instances are not.
A use-after-free in primary election catch-up
A use-after-free is a bug where software keeps using a piece of memory after it has handed it back, which can corrupt the program's state. MongoDB, acting as its own CVE numbering authority, says this one occurs when a newly elected replica set primary completes catch-up, which CNSD describes as the phase where the node applies outstanding operations before it starts accepting new writes. MongoDB scores it 9.5 under CVSS 4.0 and 9.0 under CVSS 3.1.
Peru's Centro Nacional de Seguridad Digital (CNSD), which flagged the issue in its integrated security alert No. 224-2026, says MongoDB's own security team found the bug internally. The bulletin summarises an analysis by Datadog Security Labs: an unauthenticated attacker can send ping requests carrying a readConcern.afterOpTime parameter, leaving pending waiters on the node until it restarts, rolls back or steps down. Enabling authentication does not by itself prevent this. MongoDB's fix ticket, SERVER-138119, is titled "Allow only system users to use readConcern afterOpTime."
Exploitation is not trivial. Per the CNSD summary, the targeted node has to fall behind the other members and then be elected primary. When catch-up ends, a faulty cleanup step can touch freed memory twice and crash the process. The second fix, SERVER-138175, addresses the use-after-free in CatchupState::abort() itself.
A crash shown, code execution not demonstrated
Datadog's researchers reproduced the crash on MongoDB 8.0.34 using a four-node replica set, recording a segmentation fault tied to CatchupState::abort_inlock(). They did not manage to demonstrate code execution, so that outcome reflects the risk MongoDB identified rather than a proven exploit. No exploitation in the wild has been reported in the sources reviewed.
Upgrade to 8.0.37, 7.0.48 or your branch's fix
Both fix tickets list the same patched releases:
- 9.0.7
- 8.3.16
- 8.0.37
- 7.0.48
- 6.0.30
- 5.0.35
- 4.4.32
Upgrade every member of each replica set, including shard and config server members. CNSD also recommends:
- Restricting network access to MongoDB servers to authorised hosts and keeping TCP port 27017 off the open internet, since attackers routinely mass-scan for exposed instances.
- Reviewing MongoDB's structured logs for unauthenticated ping requests carrying unusual readConcern.afterOpTime values, and for MaxTimeMSExpired errors.
- On MongoDB Atlas, confirming that maintenance updates have been applied and every cluster runs a fixed build.
It follows MongoDB's batch of 25 fixes across server and driver builds in August. The detail worth carrying away is that turning on authentication, the first control most teams reach for, does not close this one. Only the patched build and network isolation do.
This briefing is provided by IntelFusions for informational and defensive purposes only. It is based on sources assessed to be reliable at the time of writing, and analytic judgments carry the confidence levels indicated. Indicators of compromise are defanged; re-arm them only in controlled environments. IntelFusions is not affiliated with the organizations named and makes no warranty as to completeness or accuracy.