MongoDB patches pre-auth crash in replica sets (CVE-2026-118383)
MongoDB fixed a pre-auth use-after-free, CVE-2026-118383 (CVSS 9.5), that lets an unauthenticated client crash a replica set member at the next election. Patch is out for all supported branches.
MongoDB has patched CVE-2026-118383, a pre-authentication use-after-free in MongoDB Server that it rates 9.5 on CVSS 4.0. An unauthenticated client that can reach the database can plant a condition that crashes a replica set member the next time it wins an election. MongoDB disclosed the issue on 10 November, says it found the flaw internally, and is "not aware of any attempts to take advantage of this vulnerability." Datadog Security Labs reproduced the crash and published a technical analysis.
What the bug does
mongod accepts the ping command before login. An attacker sends two pings carrying a readConcern.afterOpTime value, which plants "waiters" that persist until the node restarts, rolls back, or steps down. If that member later wins an election while still lagging another member, the primary catch-up cleanup runs twice over the same state — a use-after-free — and the newly elected primary segfaults before it starts accepting writes.
The attacker does not control when an election happens or how far behind the node is, so this is a crash during an election window, not an on-demand kill switch. MongoDB's advisory says arbitrary code execution "may also result... under certain conditions"; Datadog's researchers reproduced the segfault on 8.0.34 but did not achieve code execution. A public proof-of-concept exists, but its reliable mode needs a test-only server setting a remote attacker cannot enable.
What's affected
- Replica set members, including the shard and config-server members of a sharded cluster.
- Not standalone
mongodinstances — they hold no elections. - Within each branch, every release back to the branch's first is affected.
Atlas clusters are patched automatically during maintenance; the exposure is Community Edition and self-managed Enterprise deployments that gate their own upgrades. The end-of-life 8.2 branch is not on the fixed list (8.2 reached EOL on 31 July), and MongoDB's PoC testing reportedly still crashed 8.2.12.
Fixed versions
Per MongoDB's advisory and Datadog's analysis, the first fixed release per branch:
| Branch | Fixed in |
|---|---|
| 9.0.x | 9.0.7 |
| 8.3.x | 8.3.16 |
| 8.0.x | 8.0.37 |
| 7.0.x | 7.0.48 |
| 6.0.x | 6.0.30 |
| 5.0.x | 5.0.35 |
| 4.4.x | 4.4.32 |
Action checklist
- Upgrade self-managed replica sets to the fixed release for your branch. A rolling upgrade (secondaries first, then step down the primary) applies the fix without downtime.
- Confirm standalones are actually standalone. A single-node replica set still elects, so it is in scope; a true standalone
mongodis not. - Don't rely on auth. Enabling authentication does not block the two
pingrequests on vulnerable builds — patching is the only fix. - If you run 8.2 or another EOL branch, there is no patch. Move to a supported branch.
- Restrict network exposure to the 27017 listener as defence in depth; the trigger is pre-auth, so anything that can open a connection can plant the condition.
Context
This is a denial-of-service against the availability guarantee that is the whole point of running a replica set: the attack doesn't fire until failover, which is exactly when you need the cluster to come back cleanly. The pre-auth reach — ping answered before login — is the recurring theme in database crash bugs this year, and it is the reason "it's behind auth" keeps failing as a mitigation. Treat the 27017 listener as attacker-reachable surface, not a trusted internal port.