MongoDB has patched a critical flaw that lets an attacker with no login crash a database server using just two ping requests. Tracked as CVE-2026-118383, the vulnerability carries a CVSS score of 9.5 out of 10, and researchers have already reproduced the crash in the laboratory.

MongoDB announced the fix on 10 November 2026, saying it found the problem during its own internal testing and knew of no exploitation attempts at the time. Datadog Security Labs, which investigated the flaw independently, published its findings on 11 November after crashing a test server running MongoDB 8.0.34. The flaw was one of 26 vulnerabilities MongoDB fixed in the same release.

How two ping requests can crash a server

The bug is a use-after-free flaw in the replication code that runs when a newly elected primary server finishes catching up with the rest of its replica set. During catch-up, the new primary applies the writes it missed while it was behind, and only then starts accepting new writes.

An attacker can prepare the crash in advance. Vulnerable servers accept ping requests before login, so an unauthenticated client can send two ping commands carrying a readConcern.afterOpTime value, which asks the server to wait until replication reaches a named point. Each request plants a pending notification, known as a waiter, on the target member. Turning on authentication does not prevent this, because ping is accepted before login.

The waiters alone do nothing. The crash comes later, if that same member falls behind and then wins an election, for example during maintenance or an outage. When catch-up ends, the cleanup code runs twice over memory that has already been freed, and the new primary dies before it accepts a single write. Datadog reproduced the crash three times in a four-member test replica set, and in each vulnerable run the server logged a segmentation fault with a backtrace pointing to CatchupState::abort_inlock().

The attacker cannot force the lag or the election, so the flaw is rated high in attack complexity even though it needs no privileges and no user interaction. MongoDB warns that the flaw may also allow code execution under some conditions, although Datadog did not achieve code execution in its tests.

What is affected and what is fixed

The flaw affects replica set members, including the members used by shards and config servers in sharded clusters. Standalone mongod instances are not affected, because they never run replica set primary catch-up.

Fixed releases are available for seven branches: 9.0.7, 8.3.16, 8.0.37, 7.0.48, 6.0.30, 5.0.35 and 4.4.32. MongoDB Atlas, the managed cloud service, applies the fixes during scheduled maintenance, and MongoDB urges customers who deferred maintenance to apply the update promptly. Self-managed deployments need the fixed release on every replica set member, including members in containers and any that were offline during maintenance.

One part of the installed base has no upgrade path. The 8.2 branch reached end of life on 31 July 2026 and receives no fixes, while a public proof of concept still reproduces the bug on 8.2.12 under a test-only setting. Operators still running 8.2 should move to a supported branch.

No exploitation reported, but patch now

Neither MongoDB nor Datadog has reported exploitation in the wild, and the flaw is not listed in the US Cybersecurity and Infrastructure Security Agency's Known Exploited Vulnerabilities catalog. But a public proof of concept now exists, and the attack needs only network access to a reachable replica set member.

Until every member is upgraded, MongoDB advises restricting network access to the database to only the systems that need it. That limits who can send the unauthenticated requests, but it does not fix the underlying flaw.

How to check if you were targeted

Datadog says administrators should review MongoDB's structured server logs for the planted requests. Each one appears as a slow query event with the ping command, a readConcern.afterOpTime value and an expired wait. The tell-tale crash sequence is a member entering primary catch-up, exiting catch-up twice in a single transition, and then logging a fatal signal or a backtrace involving CatchupState::abort_inlock(). A normal election logs a single catch-up exit, so a double exit followed by a crash is the signal to investigate. The requests may arrive well before the failover, so earlier logs from the same member should be reviewed too.

Source: Datadog Security Labs. See also Cyber Security News.