Critical MongoDB flaw can crash replica-set servers during failover
MongoDB disclosed a critical server flaw that can let an unauthenticated attacker crash a replica-set member after it wins a later election. The issue affects members that are still missing recent writes when they become the new primary, and MongoDB said it released fixed versions earlier this week.
The vulnerability is tracked as CVE-2026-118383 and received a 9.5 out of 10 rating on the CVSS 4.0 scale, according to MongoDB. The company said it was not aware of attempts to exploit the flaw. Researchers at Datadog Security Labs reproduced the crash in a lab and described it as a use-after-free, where the server uses memory after releasing it.
The attack uses two unauthenticated ping requests carrying a readConcern.afterOpTime value. Those requests create pending notifications on the target member. If that member later wins an election while behind, the cleanup at the end of catch-up runs twice and the new primary can crash before accepting writes. Turning on authentication does not block the requests on vulnerable versions.
The affected systems are MongoDB replica-set members, including shard and config server members in sharded clusters. A standalone mongod outside a replica set is not affected. The evidence identifies version 8.0.34 as a vulnerable test environment and 8.0.37 as rejecting both requests in the fixed test. Self-managed operators should install the fixed release on every replica-set member and verify the version on members in containers or those that were offline during maintenance.
MongoDB Atlas clusters receive fixed versions during maintenance automatically, according to the company. Customers who defer maintenance should apply the upgrade as soon as possible. Until an upgrade is possible, the researchers advise restricting database network access to systems that need it, while warning that this limits who can send the requests but does not remove the flaw.
Operators checking for attempted exploitation can review structured logs for an unauthenticated ping with readConcern.afterOpTime that ends with MaxTimeMSExpired, followed by a member entering primary catch-up and exiting it twice in one transition. A fatal signal or backtrace involving CatchupState::abort_inlock() after those exits is another reported sign. The researchers said a normal election or a single catch-up exit does not point to this flaw.