MongoDB has patched a critical use-after-free flaw, tracked as CVE-2026-118383 with a CVSS score of 9.5, that unauthenticated attackers can exploit over the network.
The company found the bug internally and says it knows of no exploitation attempts so far. The advisory warns that the flaw can crash the server or, under certain conditions, allow arbitrary code execution in the server process.
MongoDB Use-After-Free Vulnerability
The flaw sits in the replication component. It triggers when a newly elected replica set primary completes catch-up, the phase where it applies missed operations before accepting writes.
Replica set members are affected, including shard and config server members in sharded clusters. Standalone mongod instances are not. The issue is also a new MongoDB security flaw enabling arbitrary code execution, coming months after the company disclosed CVE-2026-8053, another bug it found through internal testing.
Datadog Security Labs explained how an attack could unfold. Vulnerable servers accept ping requests before login, so an unauthenticated client can send two ping commands carrying a readConcern.afterOpTime value. These leave stale “waiters” on the member, and they persist until a restart, rollback, or step-down. Enabling authentication does not prevent this.
The crash needs two further conditions the attacker cannot control. The member must fall behind and then win an election, such as during maintenance or an outage. When catch-up ends, the cleanup runs twice and touches freed memory, crashing the process before it accepts writes. The attack complexity is therefore rated high, even though it requires no privileges or user interaction.
Researchers reproduced the crash on MongoDB 8.0.34 using a four-member replica set. The target member logged a segmentation fault, and the backtrace pointed to CatchupState::abort_inlock(). The same failover on 8.0.37 rejected the pings with Unauthorized and kept running. Datadog did not achieve code execution, so the remote code execution risk remains the vendor’s assessment rather than a demonstrated exploit.
Past incidents show why quick patching matters. The MongoBleed vulnerability, CVE-2025-14847, was exploited in the wild shortly after disclosure, and public exploit code appeared within days.
Exposure also remains a persistent problem. Attackers continue to target internet-facing MongoDB instances to wipe databases and demand ransom, using mass scans for port 27017. Any replica set reachable from the internet is a likely first target for this flaw.
Affected and fixed versions
| Branch | First fixed release |
|---|---|
| 9.0 | 9.0.7 |
| 8.3 | 8.3.16 |
| 8.0 | 8.0.37 |
| 7.0 | 7.0.48 |
| 6.0 | 6.0.30 |
| 5.0 | 5.0.35 |
| 4.4 | 4.4.32 |
Administrators should upgrade every replica set member to the fixed release for their branch, then verify the running version on each node. That includes containers and members that were offline during maintenance. Atlas clusters are upgraded automatically during maintenance, but customers who defer maintenance should apply the update promptly.
Until patching is complete, restrict network access to only the systems that need it. This limits who can send the unauthenticated requests, but it does not fix the bug.
Defenders should also review MongoDB’s structured logs. Look for unauthenticated ping commands with unusual readConcern.afterOpTime values and MaxTimeMSExpired errors. Then look for a member exiting catch-up twice (log ID 21363), followed by a fatal signal. The planted requests may arrive well before the failover, so check earlier logs from the same member.
Give your SOC the alert context on the latest threats to stop incidents quickly -> Integrate Threat Intel from 16K SOCs:
