MongoDB replica sets: pre-auth use-after-free can crash servers (CVE-2026-118383)

What happened

On 10 November 2026, MongoDB disclosed CVE-2026-118383, a use-after-free in the replication component of MongoDB Server. It is rated 9.0 under CVSS. The flaw can occur when a newly elected replica set primary finishes catch-up. Requests that need no authentication can trigger it. The result can be that the server process stops unexpectedly. Under certain conditions, it can also lead to arbitrary code execution in the context of the server process.

According to The Hacker News, the risk is to a replica set member that has fallen behind and then becomes primary, for example during a failover. MongoDB has released fixes. The vulnerability is not listed in CISA's catalogue of known exploited vulnerabilities, and none of the sources report attacks.

Who is affected

• Affected: mongod processes that run as members of a replica set. This includes the shard replica sets and config server replica sets of sharded clusters.
• Not affected: standalone mongod instances that are not part of a replica set.

The flaw can be triggered before authentication, so turning on authentication does not protect you. The highest risk is to replica set members that untrusted networks or many application hosts can reach.

What to do now

1. List your replica set members. On each MongoDB server, check whether mongod runs as part of a replica set (see the next section). Standalone instances need no urgent action for this CVE.
2. Find the fixed version for your release series. The MongoDB ticket SERVER-138119 (linked below) is part of the fix. It lists fix versions 9.0.7, 8.3.16, 8.0.37, 7.0.48, 6.0.30, 5.0.35 and 4.4.32. Compare this with SERVER-138175 to confirm the version for your series.
3. Back up your configuration. Save /etc/mongod.conf (or your equivalent) and confirm that a recent backup of your data exists.
4. Upgrade one member at a time. Start with the secondaries. Upgrade the package (for example apt install mongodb-org or dnf update mongodb-org), restart mongod, and wait until the member shows SECONDARY again in rs.status(). Then run rs.stepDown() on the primary and upgrade it last. In sharded clusters, upgrade the config server replica set and every shard replica set.
5. Limit network access. Port 27017 (or your custom port) should only be reachable from application servers and the other cluster members. Use your firewall or bindIp to enforce this, both now and after the update.
6. Watch for crashes. Check the mongod logs and your service monitoring for unexpected restarts, especially around elections and failovers.

How to check whether you are affected

• Check the version with mongod --version, or in mongosh with db.version().
• Check the replica set membership in mongosh with db.hello().setName. If a name is returned, the instance is a replica set member and is affected until it is updated. If nothing is returned and rs.status() reports that the instance is not running with replication, it is a standalone instance and is not affected.
• For sharded clusters, run the check on every shard member and every config server member.
• If a member is on an older version than the fixed version for its release series, update it.

Sources

• https://nvd.nist.gov/vuln/detail/CVE-2026-118383
• https://jira.mongodb.org/browse/SERVER-138119