MongoDB flaw lets unauthenticated attackers crash servers on failover

MongoDB released patched builds earlier this week for a critical flaw in MongoDB Server that lets an unauthenticated attacker crash the database server with two requests. An unauthenticated attacker can crash the database using the flaw, tracked as CVE-2026-118383, a use-after-free flaw in which the server uses memory it already freed. MongoDB said it found the flaw itself and is not aware of any attempts to exploit it. It gave the vulnerability a 9.5 out of 10 rating on CVSS 4.0.

Datadog Security Labs researchers recreated the crash in a lab and issued their findings, according to The Hacker News. The crash occurs only if an affected server becomes primary during failover while still missing recent changes. Within a replica set, the primary processes all new writes while the remaining members copy them. If the primary becomes unavailable, the remaining members hold an election to choose a new primary, and a member that wins the election applies missed writes before it accepts new ones.

The flaw lies in the cleanup routine that runs when catch-up ends, the researchers said. Each of the two requests is a ping command that carries a readConcern.afterOpTime value and asks the server to wait until replication reaches a certain point. The server logs a pending notification, known as a waiter, with each request. Planting these waiters does not crash the server.

The waiters never expire and stay in place until the member restarts, rolls back or loses primary status.

For the crash to occur, the member that received the requests must win a later election while trailing another member. When catch-up ends, the cleanup routine runs twice and reuses memory that was already freed, which crashes the new primary before it can accept writes. Once those conditions are in place, the crash does not depend on winning a timing race, the researchers said. An attacker cannot force the targeted member to fall behind, win an election or see when either happens, according to the researchers.

In lab tests, researchers made the member fall behind and triggered a failover by using administrative access to pause and stop mongod processes. The two requests came from a client without credentials, and that client was unable to write to the database. Enabling authentication does not stop the two requests on vulnerable versions. Version 8.0.34 saw the member hit a segmentation fault, leaving the lab cluster without a primary.

Another deployment could select a new primary and keep running. On version 8.0.37, the server rejected both requests right away as unauthorized, and the member stayed running. During a proof-of-concept lab test with authentication turned off, the fixed 8.0.37 build accepted planted waiters but ran cleanup just once. The researchers said “we did not achieve code execution.”

MongoDB states that under some conditions the flaw may allow arbitrary code execution in the server process. The stated impact covers a crash or memory corruption and makes no claim of code execution. The findings do not show how often the attack would succeed in other configurations. A proof of concept posted on GitHub says version 8.2.12 still showed the bug during a lab test that used a test-only setting, and a remote attacker cannot enable that setting.

Affected members include shard members and config server members in sharded clusters. The flaw does not affect a standalone mongod running outside a replica set. Every version earlier than the fixed release in an affected branch is vulnerable, all the way back to that branch’s first release. The 8.2 branch is not listed as affected, and its latest release is 8.2.12.

The 8.2 branch reached end of life on July 31 under the company’s lifecycle schedule. After a version reaches end of life, it receives no fixes, including security fixes.

During maintenance, MongoDB Atlas clusters receive fixed versions automatically, the company’s security announcement says. Customers who put off maintenance should apply the upgrade as soon as possible. Self-managed deployments must install the fixed release on each replica set member.

After upgrading, operators should check the version on each member, including containerized members and any that were offline during maintenance. One part of the fix lets only system users use readConcern.afterOpTime, and the second part stops cleanup from running twice even if waiters already exist, the researchers said. The researchers said they had not tested that part personally. Before upgrading, researchers advise restricting database network access to only the systems that need it, which limits which systems can send the two requests but leaves the flaw unfixed.

Operators should check structured server logs for evidence of planting or a crash. One sign is a COMMAND Slow query entry logged as ID 51803. It covers an unauthenticated ping with readConcern.afterOpTime that ended in MaxTimeMSExpired. Another sign is a member entering primary catch-up under ID 21359, then exiting twice under ID 21363 during one transition.

They should also watch for a fatal signal or backtrace tied to CatchupState::abort_inlock() after those exits. This flaw is not signaled by an ordinary election or a single catch-up exit.

They should check earlier logs from the same member because the requests can arrive before the failover. Logging settings control whether request fields show up, and attr.remote might display a loopback address instead of the client’s real IP.