MongoDB CVE-2026-118383 Explained: Critical 9.5 Flaw Crashes Servers at Failover — Fixed Versions and What to Do

Illustrative image: a server room at CERN. The flaw affects MongoDB database servers — there is no product photo for a software vulnerability. Image: Wikimedia Commons / Florian Hirzinger.

TL;DR: MongoDB CVE-2026-118383 explained in one line: a critical 9.5-severity flaw lets an unauthenticated attacker crash a MongoDB replica set with two specially crafted ping requests — but only when the targeted server later wins an election and finishes catching up. MongoDB announced the fix on 10 November 2026, found the flaw itself, and says it knows of no exploitation attempts. If you run self-managed MongoDB, upgrade every replica set member to a fixed release now; Atlas clusters are patched automatically during maintenance.

Key Highlights

• What: CVE-2026-118383 is a use-after-free flaw (CWE-416) in MongoDB Server's replication code, scored 9.5 out of 10 under CVSS v4.0 and rated Critical.
• How: Two unauthenticated ping requests carrying a readConcern.afterOpTime value plant pending notifications on a replica set member. When that member later wins an election while behind on replication, the catch-up cleanup runs twice on freed memory and the new primary crashes before accepting a single write.
• Who is affected: Replica set members, including the members used by shards and config servers in sharded clusters. Standalone mongod instances are not affected, because they never perform primary catch-up.
• Exploitation: MongoDB says it found the flaw internally and is not aware of any exploitation attempts. Datadog Security Labs reproduced the crash in a lab on MongoDB 8.0.34 but did not achieve code execution; MongoDB says code execution is possible under certain conditions.
• Fix: Fixed releases are 9.0.7, 8.3.16, 8.0.37, 7.0.48, 6.0.30, 5.0.35 and 4.4.32. The 8.2 branch is end of life and has no fix — the only way out is moving to a supported branch.

What is MongoDB CVE-2026-118383?

MongoDB is a document database used by a large share of the world's web applications, and a replica set is how it stays available: several servers hold copies of the same data, one acts as the primary that takes all writes, and if the primary disappears the others elect a replacement. That election is the flaw's target. CVE-2026-118383 sits in the catch-up step — the short phase in which a newly elected primary applies the writes it missed before it starts accepting new ones.

The bug is a use-after-free, a memory error in which code keeps using a piece of memory after it has been freed. In this case the faulty step is the cleanup that runs at the end of catch-up. Under the right conditions it runs twice, the server touches memory that no longer belongs to it, and the mongod process dies with a segmentation fault. The GitHub Advisory Database records the flaw as Critical, with a network attack vector, no privileges required and no user interaction — but also high attack complexity, because the crash needs a failover the attacker cannot trigger.

MongoDB announced the security update on 10 November 2026, in a post that says the company found the vulnerability through its own proactive security programme and was not aware of attempts to exploit it at the time. Datadog Security Labs published the detailed technical write-up on 11 November, after reproducing the crash in a four-member test replica set. The flaw was not in CISA's Known Exploited Vulnerabilities catalog when MongoDB announced the fix — but that is a snapshot, not a guarantee, and a proof of concept has since been reported publicly, which is one more reason not to delay the upgrade.

How two requests can crash a database

The attack has three stages, and the attacker only controls the first. First, the attacker sends two unauthenticated ping requests to a reachable, vulnerable replica set member, each carrying a readConcern.afterOpTime value — a field that asks the server to wait until replication reaches a named point. Vulnerable servers accept ping before login, so turning on authentication does not block these two requests. Each request leaves behind a pending notification, a "waiter", that does not expire on its own. Planting the waiters does not crash anything by itself.

Second, the same member has to fall behind on replication and then win an election — something that happens on its own during maintenance or an outage. The attacker cannot cause the lag or the election, and cannot see the window opening. Third, when the new primary finishes catch-up, the cleanup runs twice and the server crashes before it accepts any writes. Datadog's lab run showed the new primary leaving catch-up twice within the same millisecond, followed by "Invalid access at address: 0" and a segmentation fault in CatchupState::abort_inlock(). In the lab the test cluster was left with no primary; in a real deployment another member might be elected and keep the service running — but a database that drops its primary at the exact moment it is meant to survive a failure is a serious problem either way.

The narrow window is real, and it is also the reason the flaw is easy to underestimate. An attacker who can reach a replica set member can leave the trap in place and wait. Failovers happen — planned maintenance, a crashed node, a network blip — and each one is a chance for the planted waiters to fire. That is why MongoDB's advice is to upgrade rather than to judge the risk by how often your clusters fail over.

Illustrative image: a data centre walkway. Image: Wikimedia Commons / 123net, CC BY-SA 3.0.

Which MongoDB versions are affected?

Every earlier release in each affected branch is vulnerable, back to the branch's first release. MongoDB published fixed releases for seven branches:

MongoDB Server branch	First fixed release
9.0	9.0.7
8.3	8.3.16
8.0	8.0.37
7.0	7.0.48
6.0	6.0.30
5.0	5.0.35
4.4	4.4.32

The fix has two parts: it restricts readConcern.afterOpTime so that only system users can use it — which stops unauthenticated clients planting the waiters — and it stops the double cleanup even when waiters are already in place. Datadog's test confirmed the first part: the patched 8.0.37 server rejected both requests as Unauthorized. The second part is covered by MongoDB's own regression tests, not by the researchers' lab run.

One branch has no fix coming. MongoDB's 8.2 branch reached end of life on 31 July 2026, so it no longer receives security fixes, and independent researchers report that the flaw still reproduces on 8.2.12 in lab conditions. If you still run 8.2, upgrading to a fixed release on a supported branch is the only way out — there is no patch to wait for.

Why it matters for Indian developers and startups

MongoDB is a default choice for a large part of India's startup and SaaS ecosystem, from early-stage products to large consumer apps, and many of those deployments are self-managed replica sets running on cloud servers — exactly the configuration this flaw hits. Atlas users are in a better position: MongoDB upgrades Atlas clusters automatically during maintenance, and only customers who deferred maintenance need to act. Self-managed users have to do the work themselves, member by member, and one unpatched member keeps the trap alive for the whole set.

The practical risk is downtime at the worst moment. A replica set exists so that a database survives a server failure; this flaw turns that survival mechanism into the crash trigger. For a team running payments, bookings, logistics or any service where a few minutes of database downtime means failed transactions, a primary that dies during failover is not a theoretical concern. No Indian victim has been named in connection with this flaw, and this post does not claim one — the point is that the exposure is architectural, not geographic, and Indian teams running self-managed MongoDB are in scope like everyone else.

The timing also matters. This is the second urgent patch window this week for widely used software, after CERT-In's warning about the exploited Chrome zero-day CVE-2026-125350 — and the same week brought attacks on managed service providers through ScreenConnect. Patching windows are getting shorter across the industry, and the teams that treat a vendor fix as a same-week job are the ones that stay ahead of the exploitation curve.

What to do now

Upgrade every affected replica set member to the fixed release for its branch, then verify the version each member is actually running — including members in containers and any that were offline during maintenance. MongoDB's own advice is explicit on this point, because a single member left on an old build keeps the whole set exposed. If you run Atlas and deferred maintenance, apply the upgrade now rather than waiting for the next window.

Until every member is upgraded, restrict network access to MongoDB so only the systems that need it can reach it. That limits who can send the two requests, but it does not fix the flaw — and enabling authentication alone does not help, because vulnerable servers accept the ping requests before login. Check your server logs for the signs Datadog documented: a COMMAND "Slow query" event (ID 51803) for an unauthenticated ping carrying readConcern.afterOpTime that ended with MaxTimeMSExpired, and a member entering primary catch-up (ID 21359) then exiting it twice (ID 21363) in one transition, followed by a fatal signal or a backtrace mentioning CatchupState::abort_inlock(). A normal election, or a single catch-up exit, does not point to this flaw — and the requests may have arrived long before the failover, so check earlier logs from the same member too.

Should you care?

✅ Yes — if you run self-managed MongoDB, patch this week. Two unauthenticated requests, no login needed, a crash that strikes during failover, and a fix that is already out: there is no reason to wait for exploitation to be confirmed. Atlas users should check that deferred maintenance is applied, and then there is nothing more to do. If you do not run MongoDB at all, forward this to whoever manages your team's databases — they are the ones who need it.

FAQs

What is CVE-2026-118383?
CVE-2026-118383 is a critical use-after-free vulnerability in MongoDB Server's replication code, scored 9.5 out of 10 under CVSS v4.0. It affects replica set members, including shard and config server members in sharded clusters. Two unauthenticated ping requests can plant pending notifications that crash the server when it later becomes primary and finishes catch-up. Standalone mongod instances are not affected.

Is MongoDB Atlas affected by CVE-2026-118383?
Atlas clusters are upgraded automatically to fixed versions during scheduled maintenance, so most Atlas users are covered without doing anything. MongoDB urges customers who deferred maintenance to apply the upgrade as soon as possible. Self-managed deployments — including Community Edition and Enterprise Advanced — must upgrade every replica set member by hand.

Which MongoDB versions fix CVE-2026-118383?
The fixed releases are 9.0.7, 8.3.16, 8.0.37, 7.0.48, 6.0.30, 5.0.35 and 4.4.32. Every earlier release in those branches is affected. The 8.2 branch has no fix because it reached end of life on 31 July 2026 — users on 8.2 must move to a supported branch.

Is CVE-2026-118383 being exploited in the wild?
MongoDB says it found the flaw internally and was not aware of any exploitation attempts when it announced the fix on 10 November 2026. Datadog Security Labs reproduced the crash in a lab but did not achieve code execution. A proof of concept has since been reported publicly, so defenders should patch on the assumption that exploitation can follow quickly.

Takeaway

MongoDB found a critical flaw in its own failover code, fixed it across seven branches, and said plainly that it knows of no exploitation yet. The window between a fix and an exploit is the cheapest time to patch — and for a bug that crashes the database at the exact moment it is supposed to survive a failure, that window is worth using. Check your replica set versions today.

For the wider pattern behind this patch, read our Citrix NetScaler vulnerabilities November 2026 explainer on 31 flaws and the builds to install — it shows how the same week produced another vendor-found, patch-now batch of critical flaws.

Sources

MongoDB — Important MongoDB security update available (Action Required), 10 November 2026
Datadog Security Labs — CVE-2026-118383: Use-after-free vulnerability in MongoDB, 11 November 2026
GitHub Advisory Database — GHSA-fjxh-6vgh-cx2c: A use-after-free in the replication component of MongoDB, published 10 November 2026
Cyber Security News — Critical MongoDB Flaw Lets Unauthenticated Attackers Crash Database Servers With Just Two Ping Requests, 12 November 2026