Two Pings. No Login. The Database Crashes.

MongoDB Server has a critical flaw that lets a remote attacker crash a database server with two requests and no login at all. The requests do not crash anything on their own. They plant a trap that waits — and it fires later, at the worst possible moment: during a failover, when a replica set member takes over as the new primary. Tracked as CVE-2026-118383, the flaw scores 9.5 out of 10, and the fix is already out.

The flaw is a use-after-free in the primary catch-up process — the step where a newly elected primary applies the writes it missed before accepting new ones. It affects replica set members, including shard and config server members. A standalone mongod, a single server outside any replica set, does not do primary catch-up and is not affected.

Two pings plant a trap that waits

The attack starts with two ping commands that carry a readConcern.afterOpTime value — a request to wait until replication reaches a certain point. Each one leaves a pending notification, called a waiter, that does not expire. It stays in place until the member restarts, rolls back, or steps down from primary.

Turning on authentication does not stop the two requests. MongoDB accepts ping before login, so an unauthenticated client can plant the waiters on any reachable, vulnerable member. Datadog Security Labs, which reproduced the crash, confirmed the same client could not write to the database — planting the trap is all it can do.

The crash needs a second act the attacker cannot stage. The member that received the requests has to win an election while it is behind another member. The attacker cannot make the member fall behind, cannot force an election, and cannot see when either happens. Both have to occur on their own — during maintenance or an outage. When catch-up ends, the cleanup runs twice, reuses memory that was already freed, and the new primary crashes before it accepts any writes.

Proven in the lab — and hard to pull off in real life

Datadog ran the same failover three times, changing only the MongoDB version and whether the two requests were sent. On 8.0.34, with both requests sent, the member exited catch-up twice in the same millisecond and crashed. Without the requests, the same failover ended with the member writable and running. On fixed 8.0.37, both requests were rejected as unauthorized at once.

That lab run took roughly 40 seconds — but the researchers are clear that this is not an estimate of how quickly a real attack would work, because they created the lag and the failover themselves with admin access. In a real deployment, the attacker plants the waiters and waits for a failover that may never come. After the crash, their test cluster had no primary; another deployment might elect a new one and keep running.

MongoDB says code execution may be possible under certain conditions. Datadog did not achieve it, and the public proof of concept claims only a crash or memory corruption — its reliable mode needs a test-only setting a remote attacker cannot enable.

Who is affected, and the fixed versions

Every earlier version in each affected branch is vulnerable, back to the branch’s first release. The fixed releases are 9.0.7, 8.3.16, 8.0.37, 7.0.48, 6.0.30, 5.0.35, and 4.4.32. MongoDB announced the update on November 10, saying it found the flaw itself and knew of no exploitation attempts.

One branch has no fix coming. The 8.2 branch reached end of life on July 31, 2026, so it no longer receives fixes — and the proof-of-concept author reports that 8.2.12 still exhibited the bug in a lab test. If you still run 8.2, the only way out is a supported branch. Atlas clusters are upgraded automatically during maintenance; self-managed deployments need the fixed release on every replica set member.

What to do now

Upgrade every affected replica set member to the fixed release for its branch, then check the version each member is actually running — including containers and any offline during maintenance. One unpatched member keeps the trap alive. Until a member can be upgraded, restrict network access to only the systems that need it; that limits who can send the two requests, but it does not fix the flaw.

Then check your logs for the signs Datadog documented. Look for a COMMAND “Slow query” entry (ID 51803) for an unauthenticated ping carrying readConcern.afterOpTime that ended with MaxTimeMSExpired. Look for a member entering primary catch-up (ID 21359), then exiting it twice (ID 21363) in one transition, followed by a fatal signal or a backtrace involving CatchupState::abort_inlock(). A normal election, or a single catch-up exit, does not point to this flaw — and the requests may have arrived long before the failover, so check earlier logs from the same member too.

The worst moment to lose a database

This is a flaw that punishes you at the exact moment your safety net is supposed to catch you. A failover exists so that losing one server does not mean losing the database — and this flaw turns the member stepping up to save the day into the one that crashes. It follows the recent run of unauthenticated remote flaws — the Linux kernel TCP flaw that gave root with no login and the OpenSSH flaw that went from patch to confirmed break-ins in days. The difference here is that the attacker cannot choose the moment. The window opens on its own, during maintenance or an outage — which is exactly when you least want a surprise. Patch every member before that window opens.