"The crash occurs only if that server is later chosen to take over as the main server while it still lacks some recent changes." That sentence, from the technical analysis, captures both the narrow trigger and the outsized risk of CVE-2026-118383: a pre-authentication bug that can topple a lagging MongoDB replica when it is promoted to primary.
What researchers reproduced in the lab
Datadog Security Labs reproduced a crash in a lab replica set and published a technical analysis showing how two unauthenticated requests can trigger a fatal failure on vulnerable MongoDB Server builds. The two client requests are ping commands that carry a readConcern.afterOpTime value. Each asks the server to wait until replication reaches a certain point; the server records a pending notification — a "waiter" — for each request. The waiters do not expire and remain until the member restarts, rolls back or steps down from primary.
In the lab, the researchers used administrative control to make one member fall behind (pausing and stopping mongod). They then caused a failover so that the behind member won an election. When that member completed its catch-up step, the cleanup code ran twice, reusing memory that had already been freed. On version 8.0.34 the result was a segmentation fault that crashed the server and left the lab cluster without a primary. The researchers described the underlying defect as a use-after-free.
Technical root cause and scope of impact
The flaw is tracked as CVE-2026-118383 and is a use-after-free in the cleanup that runs when a member finishes primary catch-up. MongoDB rated the issue 9.5 out of 10 on the CVSS 4.0 scale. Affected members include replica set members and the shard and config-server members of sharded clusters. A standalone mongod that is outside any replica set is not affected. The company said it found the flaw itself and stated it was "not aware of any attempts to take advantage of this vulnerability."
Importantly, an attacker who sends the two unauthenticated ping requests cannot by those requests alone make a member fall behind, cannot force it to win an election, and cannot observe when either condition happens, the researchers said. The crash requires the combination of planted waiters and a later election win by a still-behind member.
Your scanner finds 4,000 vulns. Which 12 matter?
Nubivance is a Rapid7 Registered Partner delivering vulnerability management as a service - scanning, risk-based prioritization, and remediation follow-through across IT and OT.
Fix the backlogFixes, behavior changes, and the proof‑of‑concept
MongoDB released fixed versions earlier this week; the vendor said each affected branch has a fixed release and that every earlier version in a branch is affected back to that branch's first release. In the fixed 8.0.37 build the server rejected both requests as unauthorized at once under one tested configuration, and one part of the fix limits use of readConcern.afterOpTime to system users. A second part of the fix prevents the cleanup from running twice when waiters are already present; Datadog did not independently test that second part.
A proof-of-concept posted on GitHub reproduces the bug in a lab replica set. Its author says the PoC's reliable mode requires a test-only setting that a remote attacker cannot enable; the PoC states an impact of crash or memory corruption and does not claim remote code execution. The researchers also note that, while MongoDB cautioned that the flaw may result in arbitrary code execution in certain conditions, they "did not achieve code execution" in their experiments and do not provide data on how often the attack would work in different deployments.
Operational guidance from MongoDB and Datadog
MongoDB Atlas clusters will automatically receive fixed versions during maintenance, the company said; customers who defer maintenance were advised to apply the upgrade as soon as possible. Self-managed deployments require installing the fixed release on every replica set member and verifying the version on each member, including containers and members that were offline during maintenance.
Until a member can be upgraded, the researchers advise restricting network access to the database to only the systems that need it. That mitigation limits which clients can send the two requests but does not eliminate the underlying vulnerability.
What this means for technologists, self-managed DBAs, and MongoDB Atlas customers
- Technologists and security teams: Check server logs for the researchers' telltale events — an unauthenticated ping with readConcern.afterOpTime that ends with MaxTimeMSExpired (COMMAND "Slow query", ID 51803); a member entering primary catch-up (ID 21359) then exiting it twice in one transition (ID 21363); and a fatal signal or backtrace involving CatchupState::abort_inlock() after those exits. Note that whether request fields are recorded depends on logging settings, and attr.remote may show a loopback address instead of the client's real IP.
- Self-managed DBAs and operators: Upgrade every replica set member to the fixed release as soon as it is available for your branch, and confirm versions on members that were offline or are running in containers. If you delay upgrades, restrict network access to only necessary systems to reduce who can send the two unauthenticated requests.
- MongoDB Atlas customers: Atlas maintenance will push the fixed versions automatically; customers who defer maintenance should accept or apply the upgrade promptly to avoid exposure.
The record here is tight: a narrowly triggered use-after-free that requires two unauthenticated reads plus a particular election timing and a lagging member. That narrowness is not comfort for operators — the bug earned a 9.5 CVSS score, replicated in lab conditions, and produced a simple crash on an unpatched build. Administrators should treat the fix as a priority, verify versions across every replica member, and hunt logs for the specific indicators Datadog published.
