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

MongoDB released fixed versions for CVE-2026-118383, a critical pre-authentication flaw in MongoDB Server that can crash a replica set member if it wins an election while still behind on replication after receiving two unauthenticated requests. The flaw is a use-after-free rated 9.5 out of 10 on the CVSS 4.0 scale. Affected members include replica set members and shard and config server members of sharded clusters, while a standalone mongod is not affected.

How the flaw works

On vulnerable versions, turning on authentication does not stop the two requests. They are ping commands carrying a readConcern.afterOpTime value, and each asks the server to wait until replication reaches a certain point, creating a pending notification called a waiter. The waiters do not expire and remain until the member restarts, rolls back, or steps down from primary. The crash happens when the member that received them wins a later election despite being behind another member; when catch-up ends, cleanup runs twice and reuses freed memory, crashing the new primary before it accepts writes. Researchers said that once those conditions are met, the crash does not depend on winning a timing race, and an attacker cannot make the targeted member fall behind or win an election, or see when either happens.

Affected versions and fixes

MongoDB released a fixed version for each affected branch, and every earlier version in a branch is affected back to the branch's first release. Self-managed deployments need the fixed release on every replica set member, and after upgrading administrators should check the version each member is running, including members in containers and any that were offline during maintenance. MongoDB Atlas clusters automatically receive fixed versions during maintenance, and customers who defer maintenance should apply the upgrade as soon as possible. The 8.2 branch is not among the affected versions listed, and its newest release is 8.2.12, but a proof of concept published on GitHub reports that 8.2.12 still exhibited the bug in a lab test using a test-only setting. The 8.2 branch reached end of life on July 31, according to the company's lifecycle schedule.

Detection and mitigation

Until a member can be upgraded, researchers advise restricting network access to the database to only the systems that need it, which limits who can send the two requests but does not fix the flaw. To look for planting or a crash, check structured logs for a COMMAND Slow query entry with ID 51803 for an unauthenticated ping carrying readConcern.afterOpTime that ended with MaxTimeMSExpired; a member entering primary catch-up with ID 21359 and then exiting it twice with ID 21363 in one transition; and a fatal signal or backtrace involving CatchupState::abort_inlock() after those exits. The requests may arrive before the failover, so earlier logs from the same member should also be checked.

Code execution claims

MongoDB says the flaw may also result in arbitrary code execution in the server process under certain conditions. In the lab, the researchers said they did not achieve code execution, and their results do not show how often the attack would work in other setups. The proof-of-concept code reproduces the bug in a lab replica set; its reliable mode requires a test-only setting that a remote attacker cannot enable, and its stated impact is a crash or memory corruption. In the proof-of-concept lab test with authentication turned off, fixed 8.0.37 accepted the planted waiters but ran the cleanup only once.

Sources: The Hacker News