MongoDB fixes a critical replication flaw that lets unauthenticated attackers crash servers and, in some conditions, run code

What happened

MongoDB published a security alert on 10 November 2026 for CVE-2026-118383 in MongoDB Server. It is a use-after-free (CWE-416) in the replication code. MongoDB, acting as the CNA, scores it 9.5 under CVSS 4.0 and 9.0 under CVSS 3.1 - critical. Fixed releases are out for every line from 4.4 to 9.0.

According to MongoDB, the flaw can be triggered by unauthenticated requests. The result is a server crash and, under certain conditions, arbitrary code execution. MongoDB found the issue internally and does not mention exploitation.

MongoDB issued alerts for several other bugs the same day (for example CVE-2026-120828, memory exhaustion, 8.7). This article covers the most serious one.

Technical details

• Component: replication in MongoDB Server, specifically the catch-up phase after a new replica set primary is elected.
• Bug class: use-after-free. Ticket SERVER-138175 describes it as re-entrancy into CatchupState::abort().
• Conditions: the attacker only needs network access to a replica set member - no credentials and no user interaction. The bug only fires while a newly elected primary is completing catch-up, hence the high attack complexity (AC:H).
• Fix: alongside the bug fix, MongoDB restricted the afterOpTime read concern to internal system users (SERVER-138119).

For context: a replica set is the standard way to run MongoDB in production. One primary accepts writes, secondaries keep copies of the data, and if the primary goes down they elect a new one. The new primary first pulls any recent writes it is missing from the other members (the catch-up phase, bounded by settings.catchUpTimeoutMillis) and only then starts accepting writes. The bug is hit when that phase ends.

MongoDB has not released proof-of-concept code, and neither do we.

Who is affected

Affected nodes are replica set members, including shard and config server members. Standalone mongod is not affected, according to MongoDB. Check the version and role in mongosh:

db.version()
rs.status().members.map(m => [m.name, m.stateStr])

How to tell if you were compromised

MongoDB has not published indicators of compromise. From our experience:

• Review the mongod log around primary elections (election and catchup entries) for unexpected process crashes or restarts by systemd or Kubernetes.
• Check which addresses outside your application servers connected to the database port (27017 by default). Our IOC extractor pulls IP addresses out of logs and runs entirely in your browser.
• If you suspect code execution, investigate processes and files created under the account that runs mongod.

What to do

1. Upgrade every member of the replica set to the fixed release for its line - secondaries first, then the primary after rs.stepDown(). Keep in mind that a primary election is exactly when the bug fires, so restrict network access before you start.
2. Restrict database access: the MongoDB port should only be reachable from application servers and other cluster members (firewall, net.bindIp). Authentication does not protect against this flaw. This is our recommendation; MongoDB lists no workarounds.
3. Find out where the database listens: run ss -tlnp | grep mongod on the server and check net.bindIp in /etc/mongod.conf. A value of 0.0.0.0 means all interfaces, so your firewall has to do the filtering.
4. Confirm the version with db.version() on every member after upgrading.
5. Update distribution packages and container images (such as mongo:8.0) as their publishers release fixes.

Timeline

Updates

• 12 Nov 2026 - first version of this article.