Newshot 
MongoDB has fixed a critical vulnerability tracked as CVE-2026-118383 that allows a remote unauthenticated attacker to crash a database server by sending just two simple ping requests. The flaw has a CVSS v4.0 score of 9.5.
The vulnerability resides in the replication code path that runs after a new primary finishes catching up on data. MongoDB published a fix advisory on November 10, 2026, stating that the issue was found internally and that no in-the-wild exploitation attempts have been observed so far.
The flaw is a use-after-free that unauthenticated requests can trigger
According to the GitHub security advisory, the vulnerability is a use-after-free defect, meaning the program continues to access a region of memory after that memory has already been freed.
Requests that require no authentication can trigger the defect, ultimately causing the server to shut down abruptly. Under specific conditions, an attacker may also be able to achieve arbitrary code execution within the server process.
Only replica set members are affected, including shard nodes and config server nodes in a sharded cluster. Standalone mongod processes do not run the primary catch-up step and are therefore not affected by the vulnerability.
MongoDB election timeline (Image credit: Datadog Security Labs)
Researchers at Datadog Security Labs disclosed the full chain that triggers the flaw. After a replica set member wins an election and becomes the new primary, it first backfills previously missed writes before accepting new write requests. The vulnerability lies in the cleanup routine that runs after this catch-up step completes.
A vulnerable server can accept ping commands before login. An attacker only needs to send two ping requests carrying the readConcern.afterOpTime parameter, and each request leaves behind a pending notification, which MongoDB calls a waiter. Such waiters initially have no effect and persist until the corresponding node restarts, rolls back, or steps down as primary.
Triggering a server crash also requires two preconditions the attacker cannot control: a replica set node falls behind on data synchronization, and that node subsequently wins an election to become the new primary. Such scenarios typically occur during system maintenance or service outages.
When the catch-up process ends, the cleanup logic runs twice, accessing an already freed memory region. The server crashes before accepting any new writes, and enabling authentication cannot block this initial trigger path.
The Datadog researchers built a four-node replica set test environment and deliberately created node lag and failover scenarios. After sending two ping requests in an environment running MongoDB 8.0.34, the new primary logged a segmentation fault and the process crashed outright.
Without those two requests, the same failover process runs normally. In the patched 8.0.37 version, the server rejects the two requests as "unauthorized" and continues running normally.
The research team did not achieve code execution in its testing. The team also cautioned that the roughly 40-second trigger time in testing does not represent attack speed in real-world environments. An attacker cannot observe or choose the trigger window, which is why the CVSS rating scores the vulnerability's attack complexity as "High."
Official patches released across all versions, admins should upgrade promptly
MongoDB has released fixes covering all version branches, with corresponding version numbers 9.0.7, 8.3.16, 8.0.37, 7.0.48, 6.0.30, 5.0.35, and 4.4.32. Atlas clusters will upgrade automatically during maintenance windows, and MongoDB urges users who previously deferred maintenance to apply the updates as soon as possible.
Administrators running self-hosted servers need to check the version of every node, including container instances and nodes that were offline while patches were being installed.
If an immediate upgrade is not possible, restrict network access to the database service and expose it only to systems that genuinely need it. This approach can narrow the set of parties able to send ping requests, but it does not fundamentally fix the vulnerability.
After the primary crashes, the cluster loses write capability until another node takes over. Datadog's testing showed that the cluster remained in a primary-less state for an extended period after the crash.
Detection rules for logs, and vigilance against in-the-wild exploitation
Datadog recommends that administrators inspect server structured logs for slow-query entries for ping commands that carry the readConcern.afterOpTime parameter and contain waiter expiry records.
They should also look for a node that exits sync state twice during a single primary failover, and for subsequent fatal signals mentioning CatchupState::abort_inlock(). Whether these fields are visible depends on the logging configuration, and administrators need to confirm that logs record the full command contents.
This is not the first MongoDB vulnerability this year that can be triggered before login. This site previously reported on CVE-2026-25611, a compression-related flaw that lets an unauthenticated attacker crash a server with only minimal bandwidth.
We also previously reported on the MongoBleed memory disclosure vulnerability, which saw in-the-wild exploitation very soon after disclosure. The MongoBleed incident shows how quickly attackers move once vulnerability details become public.
Teams should complete patching of the latest vulnerability before similar in-the-wild exploitation occurs, and should avoid exposing database ports to the public internet. The official record for CVE-2026-118383 can be found in its NVD entry, and MongoDB's internal tracking ticket numbers are SERVER-138119 and SERVER-138175.
Critical MongoDB Flaw Lets Attackers Crash Database Servers With Just Two Ping Requests