Key points and observations
- CVE-2026-118383 is a critical use-after-free in MongoDB Server's primary catch-up process, with a CVSS v4.0 score of 9.5. It affects replica set members, including those used by shards and config servers. Standalone
mongodinstances are unaffected. - Remote unauthenticated exploitation is possible, but only during a specific window that the attacker does not have visibility into.
- We reproduced a crash (segmentation fault) on MongoDB Server 8.0.34.
- An unauthenticated client can set up the crash with two
pingrequests, because vulnerable servers acceptpingbefore login. Turning on authentication does not prevent this. - Upgrade every affected replica set member to a fixed release. Restricting network access can reduce exposure while you upgrade.
What happened
MongoDB announced a security update on November 10. The company said it found the vulnerability internally and was not aware of exploitation attempts at the time of its announcement. The advisory describes a use-after-free when a newly elected replica set primary completes catch-up. During catch-up, the member applies operations it missed before accepting writes as primary.
The vulnerability affects ordinary replica set members. It also affects the replica set members used by shards and config servers in sharded clusters. A standalone mongod does not perform replica set primary catch-up and is not affected by this vulnerability. The advisory rates the issue Critical and says the server may terminate unexpectedly or, under certain conditions, execute arbitrary code in the server process.
How to know if you are affected
The issue affects replica set members, including shard and config server replica set members in sharded clusters. Standalone mongod instances are not affected.
The MongoDB fix releases are:
| MongoDB Server 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 |
Upgrade to the fixed release for your branch, or use a distributor package that includes the fix. Verify the version running on every member after the upgrade, including members in containers and any members that were offline during maintenance. MongoDB says Atlas clusters are upgraded automatically during maintenance. It urges customers who defer maintenance to apply the upgrade promptly.
Until you can upgrade, restrict network access to MongoDB to the specific systems that need access to it. This limits who can send the unauthenticated requests, but it does not fix the use-after-free.
Exploitation window and likelihood
When a replica set member wins an election, it first catches up on writes it missed, then starts accepting new ones. The bug is in the cleanup at the end of that catch-up step. Before any election happens, an attacker can leave two stale “waiters” on a member. A waiter is a pending notification MongoDB creates when a request asks to wait until replication reaches a certain point. Planting them does not crash the server by itself. The diagram below traces an election timeline and marks where the crash fires.
- Plant during steady state: The attacker sends two unauthenticated
pingrequests that include areadConcern.afterOpTimevalue to a reachable, vulnerable replica set member. The waiters don't expire. They stay in place until the member restarts, rolls back, or steps down from primary. - Reach catch-up: Later, the same member has to win an election while it is behind another member. The attacker can't cause the lag or the election. Both have to happen on their own, for example during maintenance or an outage.
- Crash when catch-up ends: When catch-up finishes, the new primary runs its cleanup twice, uses memory it has already freed, and crashes before it accepts any writes. Once the first two steps are in place, the crash does not depend on winning a timing race.
We created the lag and the failover ourselves, so the roughly 40 seconds our lab run took is not an estimate of how quickly a real attack would work. After the crash, our test cluster had no primary. Another deployment might elect a new primary and keep running.
What we reproduced
We built a four-member replica set from MongoDB's official Linux x86_64 binaries and created the two conditions an attacker can't control: one member falling behind on replication, and a failover that makes that member the new primary. Setting this up took admin access to the lab, to pause and stop mongod processes and to write data with an authenticated client. The attacker's part, the two ping requests, used no credentials, and we confirmed that the same unauthenticated client could not write to the database.
We ran the same failover three times, changing only the MongoDB version and whether we sent the two requests:
| Run | Server | Unauthenticated waiter requests | Observed result |
|---|---|---|---|
| A | 8.0.34 | Both timed out after about 1.5 seconds with MaxTimeMSExpired |
The target member exited catch-up twice, logged SIGSEGV, and the mongod process crashed |
| B | 8.0.34 | None sent | The target member exited catch-up once, became writable, and remained running through the observation window |
| C | 8.0.37 | Both rejected immediately with Unauthorized |
The target member exited catch-up once, became writable, and remained running through the observation window |
The video below shows run A from start to finish: the two unauthenticated requests, the failover we triggered, and the new primary crashing.
In run A, MongoDB's log shows the new primary leaving catch-up mode twice within the same millisecond, followed by “Invalid access at address: 0” and “Got signal: 11 (Segmentation fault).” The backtrace points to CatchupState::abort_inlock(). Runs B and C went through the same failover, logged a single catch-up exit, and kept running.
Run C shows that the patched server refuses the requests. It does not test the other half of MongoDB's fix, which stops the double cleanup even when waiters are already in place; MongoDB's own regression tests cover that case. Our results show that the crash can be set up without credentials in this lab setup. They don't tell us how often it would succeed in other topologies, and we did not achieve code execution.
How to detect exploitation attempts
Start with MongoDB's structured server logs. In our vulnerable run, each planted request appeared as a COMMAND “Slow query” event (ID 51803). The useful fields were:
attr.command.pingattr.command.readConcern.afterOpTimeattr.command.maxTimeMSattr.errName(MaxTimeMSExpired)attr.durationMillisattr.remote
Look for an unauthenticated command with unusual operation-time values and an expired wait.
Also check the logs for the sequence that preceded a crash: a member enters primary catch-up (ID 21359), exits catch-up twice (ID 21363) in one transition, and then logs a fatal signal or backtrace involving CatchupState::abort_inlock(). A normal election or a single catch-up exit does not identify this CVE. The requests may arrive before the failover. Review earlier logs from the same member, not just events around the crash.
Whether these request fields appear in the logs depends on your logging settings. MongoDB documents that client operations enter the diagnostic log when they exceed the slow-operation threshold or when command verbosity is at least one. Check whether your logs retain the command object. Slow-operation sampling or a log pipeline may drop it. The attr.remote field may contain a loopback address rather than the original client IP.
How Datadog can help
Datadog Cloud Security Management reports findings for CVE-2026-118383. Check the vulnerability findings for affected hosts and container images.
Datadog Cloud Security Management also flags security groups that allow inbound MongoDB access from the internet, through the rule Inbound MongoDB access should be restricted. Use it to find exposed replica set members to patch first. Datadog Cloud SIEM detections for CVE-2026-118383 are currently being evaluated, and we will update this post when they are available.
Conclusion
CVE-2026-118383 affects MongoDB replica set members when a newly elected primary finishes catch-up. We reproduced a crash after two unauthenticated requests left abandoned waiters. The patched release rejected those requests. The vendor also identifies arbitrary code execution as a possible impact under certain conditions; our tests did not demonstrate it. Upgrade every affected member to a fixed release, verify the running versions, and investigate unusual readConcern.afterOpTime requests alongside catch-up and crash events.
