Critical Pre-Auth MongoDB Flaw (CVE-2026-118383) Can Crash Servers on Failover

A critical pre-authentication vulnerability, tracked as CVE-2026-118383, has been discovered in MongoDB Server, posing a significant risk to database availability. The flaw, rated 9.5 out of 10 on the CVSS 4.0 severity scale, allows an unauthenticated attacker to trigger a server crash by sending two specific requests. This crash is particularly impactful as it occurs on a server that has been elected to become the new primary during a failover event, provided it has not yet synchronized recent changes from the previous primary.

Researchers at Datadog Security Labs detailed the vulnerability, explaining that it is a use-after-free condition where the server attempts to use memory that has already been freed. Crucially, enabling authentication does not mitigate this specific flaw, as the malicious requests can still be sent by an unauthenticated attacker. The vulnerability affects shard and config server members of sharded clusters, as well as members of replica sets. Standalone MongoDB servers are not impacted.

MongoDB has responded swiftly by releasing patched versions of its server software. Customers using MongoDB Atlas will receive these updates automatically during scheduled maintenance. For self-managed deployments, it is imperative that administrators apply the security upgrades to every member of their replica sets as soon as possible. The company stated it discovered the flaw internally and is not aware of any active exploitation in the wild.

While the primary impact is a server crash, MongoDB also noted that under certain conditions, the flaw could potentially lead to arbitrary code execution. However, the researchers who discovered the vulnerability were unable to achieve code execution in their lab environment. The proof-of-concept code developed also indicates a crash or memory corruption as the main outcome, with no claims of code execution.

The vulnerability lies within the cleanup process that runs when a replica set member, which has fallen behind, is elected as the new primary and begins to catch up. The two malicious requests, which include a readConcern.afterOpTime value, plant "waiters" that do not expire. When the server later wins an election and attempts to catch up, the cleanup routine runs twice due to the presence of these waiters, leading to the use-after-free condition and subsequent crash.

To mitigate the risk until patches can be applied, Datadog Security Labs advises restricting network access to the database to only essential systems. This measure limits the attack surface by preventing unauthorized entities from sending the malicious requests. However, it does not fix the underlying vulnerability.

MongoDB has released fixes across various branches, including versions 8.0.37 and 7.0.17, among others. It is important to note that the 8.2 branch, which reached end-of-life on July 31, 2026, will no longer receive security fixes, including for this vulnerability. A proof-of-concept report indicated that even version 8.2.12 might still exhibit the bug, underscoring the urgency for users on supported versions to upgrade.

Security teams can look for signs of attempted exploitation in their server logs. Indicators include "Slow query" entries for unauthenticated pings with readConcern.afterOpTime that result in MaxTimeMSExpired, or a member exiting its primary catch-up state twice in a single transition, followed by a fatal signal related to CatchupState::abort_inlock(). These log events, especially when occurring before or during a failover, could point to an attempted attack.