A critical flaw in MongoDB Server allows an unauthenticated attacker to send two requests that trigger a crash on the database server. The crash occurs only if that server is later chosen to take over as the main server while it still lacks some recent changes.
MongoDB, the company that makes the database, released fixed versions earlier this week.
The affected servers are members of a replica set, a group of MongoDB servers that keep copies of the same data. One member, the primary, serves as the main server and handles all new writes, while the others replicate them. If the primary becomes unavailable, the other members hold an election to pick a new primary.
Researchers at Datadog Security Labs reproduced the crash in a lab and published their findings yesterday. On vulnerable versions, turning on authentication does not stop the two requests. An attacker cannot make the targeted member fall behind or win an election, or see when either happens, the researchers said.
The flaw, tracked as CVE-2026-118383, is a use-after-free: the server ends up using memory it has already freed. MongoDB rated it 9.5 out of 10 on the CVSS 4.0 severity scale. The company said it found the flaw itself and was “not aware of any attempts to take advantage of this vulnerability.”
Affected members include the shard and config server members of sharded clusters. A standalone mongod, a single server outside any replica set, is not affected.
Each affected branch has a fixed release, listed below and in the CVE record. Every earlier version in a branch is affected, back to the branch’s first release.
MongoDB Atlas clusters automatically receive fixed versions during maintenance, the company said in its security announcement. Customers who defer maintenance should apply the upgrade as soon as possible.
Self-managed deployments need the fixed release on every replica set member. After upgrading, check the version each member is running, including members in containers and any that were offline during maintenance.
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. Past that date, a version no longer receives fixes, including security fixes.
Until a member can be upgraded, the researchers advise restricting network access to the database to only the systems that need it. That limits who can send the two requests but does not fix the flaw.
A member who wins an election first catches up by applying the writes it missed before it accepts new ones. The flaw is in the cleanup that runs when this catch-up step ends, according to the Datadog researchers’ technical analysis.
The two requests are ping commands that carry a readConcern.afterOpTime value. Each asks the server to wait until replication reaches a certain point, and the server records a pending notification for it, called a waiter.
Planting the waiters does not crash the server. They do not expire, and stay in place until the member restarts, rolls back or steps down from primary.
The crash needs the member who received the requests to win a later election, even though it is behind another member. When catch-up ends, the cleanup runs twice, reusing memory that was already freed, and the new primary crashes before it accepts any writes. Once those conditions are met, the crash does not depend on winning a timing race, the researchers said.
In the lab, the researchers caused the member to fall behind and forced a failover themselves by using admin access to pause and stop mongod processes. Only the two requests came from a client without credentials, and that client could not write to the database.
On version 8.0.34, the member crashed with a segmentation fault, leaving the lab cluster without a primary. Another deployment might elect a new primary and keep running.
In the fixed version 8.0.37, the server rejected both requests as unauthorized at once, and the member kept running. One part of the fix lets only system users use readConcern.afterOpTime.
MongoDB says the flaw may also result in arbitrary code execution in the server process under certain conditions. In the lab, though, “we did not achieve code execution,” the researchers said. Their results also 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, according to its author. Its reliable mode requires a test-only setting that a remote attacker cannot enable. Its stated impact is a crash or memory corruption, with no claim of code execution.
The second part of the fix stops the cleanup from running twice even when waiters are already in place, the researchers said. They did not test that part themselves.
In the proof-of-concept lab test, which ran with authentication turned off, the fixed 8.0.37 accepted the planted waiters but ran the cleanup only once.
To look for planting or a crash, check the server’s structured logs for these signs from the researchers’ vulnerable run:
- Log event: a COMMAND “Slow query” entry (ID 51803) for an unauthenticated ping carrying readConcern.afterOpTime that ended with MaxTimeMSExpired.
- Log event: a member entering primary catch-up (ID 21359), then exiting it twice (ID 21363) in one transition.
- Log event: a fatal signal or backtrace involving CatchupState::abort_inlock() after those exits.
A normal election or a single catch-up exit does not point to this flaw. The requests may also arrive before the failover, so check earlier logs from the same member too.
Whether the request fields are logged depends on logging settings, and the attr.remote field may show a loopback address instead of the client’s real IP.
