MongoDB announced on November 10 that it had fixed a critical flaw in MongoDB Server, tracked as CVE-2026-118383 and rated 9.5 out of 10 on the CVSS 4.0 scale. The company said it found the flaw itself and is “not aware of any attempts to take advantage of this vulnerability.” It is a use-after-free: the server keeps using a piece of memory after it has been released. It happens when a newly elected primary in a replica set (a group of MongoDB servers that keep copies of the same data) finishes catching up on writes it missed. MongoDB says the server may terminate unexpectedly or, under certain conditions, run code inside the server process.
Datadog Security Labs published an analysis on November 11. Its researchers say an unauthenticated client can set up the crash with two ping requests carrying a readConcern.afterOpTime value, because vulnerable servers accept ping before login, and turning on authentication does not prevent that. The crash only happens if the member that received the requests later wins an election while it is still behind, and the researchers note an attacker cannot make that happen or see when it does. In a lab replica set on MongoDB 8.0.34 the member crashed with a segmentation fault; on 8.0.37 both requests were rejected and the member kept running. Datadog says its tests did not achieve code execution. The Hacker News adds that a public proof-of-concept reproduces the crash in a lab and that its reliable mode needs a test-only setting a remote attacker cannot enable.
How to check if you’re affected
Affected products are self-managed MongoDB Server deployments that run as replica set members, including the shard and config server members of sharded clusters. A standalone mongod outside any replica set is not affected. Affected versions are every release earlier than the first fixed release in its branch. Datadog lists the first fixed releases as 9.0.7, 8.3.16, 8.0.37, 7.0.48, 6.0.30, 5.0.35 and 4.4.32. Upgrade each member to the fixed release for its branch, then verify the version actually running on every member, including members in containers and any that were offline during maintenance.
MongoDB says Atlas clusters are upgraded automatically during maintenance and urges customers who defer maintenance to apply the upgrade promptly. Until a member can be upgraded, Datadog’s researchers advise limiting network access to the database to the systems that need it; that reduces who can send the requests but does not fix the flaw.
The Hacker News notes that the 8.2 branch is not among the listed affected versions but reached end of life on July 31, and that the proof-of-concept author reports 8.2.12 still crashed in a lab test using the test-only setting. To look for signs of planting or a crash, THN lists these entries from the researchers’ vulnerable run: a “Slow query” log entry (ID 51803) for an unauthenticated ping with readConcern.afterOpTime that ended in MaxTimeMSExpired; a member entering primary catch-up (ID 21359) and then exiting it twice (ID 21363) in one transition; and a fatal signal involving CatchupState::abort_inlock(). Check logs from before the failover too, since the requests may arrive earlier. Datadog’s page also promotes its own detection products.
Sources
- MongoDB Community Hub: Important MongoDB security update available (Action Required), November 10, 2026
- Datadog Security Labs: CVE-2026-118383, Use-after-free vulnerability in MongoDB
- The Hacker News: Critical Pre-Auth MongoDB Flaw (CVE-2026-118383) Can Crash Lagging Servers on Failover
- CVE record for CVE-2026-118383 (linked from The Hacker News; the page is a script-rendered shell, so its contents were not read directly)