Severity: Critical | Priority: 1
MongoDB has fixed a critical use-after-free vulnerability, CVE-2026-118383 (CVSS v4.0 9.5), in the replication component of MongoDB Server. It affects every replica set member, including the members that make up shards and config servers in a sharded cluster. Standalone mongod instances are not affected. The flaw is in the cleanup that runs when a newly elected primary finishes catching up on writes it missed before it starts accepting new ones. Under certain conditions that cleanup runs twice and touches memory that has already been freed.
An attacker doesn’t need credentials. They only need network access to a vulnerable replica set member. A pair of unauthenticated requests carrying an internal replication parameter leaves waiting operations on the server that never expire, and nothing visible happens at that point. The server crashes later, if that member is elected primary while it is behind the rest of the set. Because of this gap, the attack can be set up long before the outage and look unrelated to it. Researchers have reproduced the crash but haven’t shown code execution. A public proof-of-concept is available. MongoDB found the issue internally and says it is not aware of exploitation.
Upgrade every replica set member in your network to a fixed release: 9.0.7, 8.3.16, 8.0.37, 7.0.48, 6.0.30, 5.0.35 or 4.4.32, or later. Check the versions actually running afterwards. Until then, and as standard practice, make sure MongoDB ports can only be reached from the application servers and cluster members that need them, never from the internet or general user networks.
To check whether anyone has attempted this, search the MongoDB logs for unauthenticated ping, hello or isMaster commands that carry readConcern.afterOpTime and ended with a MaxTimeMSExpired error. Also look for unexpected crashes of a member just after it was elected primary.