Vulnerability
A critical use-after-free vulnerability affects the replication component in MongoDB Server. It can occur when a newly elected replica set primary completes catch-up.
The triggering condition can be set up by requests that don’t require authentication. An unauthenticated client can set it up with two ping requests, because vulnerable servers accept ping before login. Turning on authentication doesn’t prevent it.
The two requests leave an abandoned state behind on a replica set member. The crash happens only if that member later falls behind on recent changes, is elected primary and finishes catch-up.
Researchers say an attacker can’t make a member fall behind or win an election, or see when either happens.
CVE and severity
The vulnerability is tracked as CVE-2026-118383.
It’s rated critical, with a CVSS 4.0 score of 9.5 and a CVSS 3.1 score of 9.0.
The CVSS vector lists high attack complexity, because of the timing the crash depends on.
Impact
The main demonstrated impact is a server crash, which can disrupt a replica set at the moment of failover.
The CVE description also says arbitrary code execution in the context of the server process is possible under certain conditions. Code execution hasn’t been publicly demonstrated.
Exploit status
MongoDB found the flaw internally and announced the fix on November 10, 2026. The company says it isn’t aware of any attempts to exploit it.
As of November 10, 2026, there was no public exploit code, and the flaw wasn’t in the CISA Known Exploited Vulnerabilities (KEV) catalog.
Affected component and versions
MongoDB Server replica set members are affected, including the shard and config server replica set members of sharded clusters. Standalone mongod instances aren’t affected.
Affected versions:
- 9.0.0 up to, but not including, 9.0.7
- 8.3.0 up to, but not including, 8.3.16
- 8.0.0 up to, but not including, 8.0.37
- 7.0.0 up to, but not including, 7.0.48
- 6.0.0 up to, but not including, 6.0.30
- 5.0.0 up to, but not including, 5.0.35
- 4.4.0 up to, but not including, 4.4.32
The flaw is fixed in 9.0.7, 8.3.16, 8.0.37, 7.0.48, 6.0.30, 5.0.35 and 4.4.32.
Fix and mitigation
- Upgrade every affected replica set member to a fixed release, including shard and config server members. MongoDB strongly recommends that all Community Edition users upgrade as soon as possible.
- Until each member is upgraded, restrict network access to the database so only the systems that need it can reach it. This limits who can send the two requests, but it doesn’t fix the flaw.
- Don’t rely on enabling authentication as a mitigation. Vulnerable versions accept the triggering requests before login.
- Check any replica set that has been exposed to untrusted networks, including internet-exposed MongoDB instances.
- Prioritize members that lag behind on replication. They’re the ones that could crash if elected primary.
- Monitor for unexpected
mongodcrashes or restarts, especially around elections and failovers.
