+61 2 9043 1246

Knowledge base

CVE-2026-118383: the MongoDB Server replica set flaw, explained for website owners

Published · By , Co-Founder, BLACKBX

CVE-2026-118383 is a critical flaw in MongoDB Server that lets requests with no login crash a replica set database, and under certain conditions run code on it. MongoDB fixed it on 10 November 2026. No attacks are reported, but a public crash demonstration exists. Update every replica set member to a fixed release.

Key fact CVE-2026-118383
What A use-after-free memory bug (CWE-416) in MongoDB Server’s replication component, triggered when a newly elected primary finishes catch-up.
Affected Replica set members (including shard and config server members) on 4.4.0 to before 4.4.32, 5.0.0 to before 5.0.35, 6.0.0 to before 6.0.30, 7.0.0 to before 7.0.48, 8.0.0 to before 8.0.37, 8.3.0 to before 8.3.16 and 9.0.0 to before 9.0.7. A standalone mongod is not affected. Whether 8.1 and 8.2 are affected is not known; both are end of life.
Fixed in 4.4.32, 5.0.35, 6.0.30, 7.0.48, 8.0.37, 8.3.16 and 9.0.7, released 10 November 2026. Latest today: 9.0.8, 8.3.17, 8.0.38, 7.0.48, 6.0.30, 5.0.35 and 4.4.32.
Severity 9.5 Critical (CVSS 4.0) and 9.0 Critical (CVSS 3.1), both assigned by MongoDB. NVD has not given its own score.
Needs a login? No. Turning on authentication does not prevent it on vulnerable versions.
Exploited? Not known to be. No attacks reported as of 13 November 2026, but public proof-of-concept code that crashes the server has been out since 11 November. Not in CISA KEV as of 13 November.
Do now Update every member of each MongoDB replica set to a fixed release.

Facts checked on 14 November 2026 against MongoDB’s security notice and release notes, the CVE record and NVD data (via OpenCVE and threatint), Datadog Security Labs, The Hacker News, Ostorlab and endoflife.date. Sources are listed at the end.

What is CVE-2026-118383?

MongoDB is a database: the software that stores the information a website or web app works from, such as customer accounts, orders, bookings or content. It is made by MongoDB, Inc., and MongoDB itself issued this CVE.

Many MongoDB installations run as a replica set. That is a group of MongoDB servers that each keep a copy of the same data. One server, the primary, handles all new writes, and the others copy what it does. If the primary becomes unavailable, the others hold an election and pick a new one. Before a newly elected primary starts accepting writes, it applies any changes it missed. MongoDB calls that step catch-up.

CVE-2026-118383 sits in the part of MongoDB that keeps those copies in sync, the replication component. MongoDB’s own title for it is “Pre-authentication use-after-free in MongoDB Server replica set primary catch-up”. A use-after-free (classified as CWE-416) is a memory bug: the software goes back to use a piece of memory it has already handed back, and whatever is in that memory at the time can make the program misbehave.

In plain terms, someone who can reach your database over the network, without logging in, can leave requests waiting on a replica set member. If that server later becomes the primary while it is behind on recent changes, finishing catch-up can crash it. The CVE record says that under certain conditions it could also allow code to be run on the server with the database’s own permissions.

MongoDB found the bug itself through what it calls its “proactive security program”. When it was discovered is not public. The CVE number was reserved on 28 October 2026, and MongoDB announced the fix and released fixed versions on 10 November 2026. MongoDB’s internal tracking tickets are SERVER-138119 and SERVER-138175. MongoDB’s notice describes it as a vulnerability “that could allow unauthorized access to the MongoDB Server” and marks it “Action Required”.

Who is affected?

Your site or app is in scope if all of these are true:

  1. It keeps its data in MongoDB Server.
  2. That MongoDB runs as a replica set, or as a sharded cluster (a larger setup whose shards and config servers are themselves replica sets).
  3. The MongoDB version falls in one of these ranges:
    • 4.4.0 up to but not including 4.4.32
    • 5.0.0 up to but not including 5.0.35
    • 6.0.0 up to but not including 6.0.30
    • 7.0.0 up to but not including 7.0.48
    • 8.0.0 up to but not including 8.0.37
    • 8.3.0 up to but not including 8.3.16
    • 9.0.0 up to but not including 9.0.7
  4. Someone outside your organisation can reach the database server over the network.

What is not affected:

  • A standalone MongoDB server, meaning a single mongod that is not part of a replica set. It never does primary catch-up, so it never reaches the faulty code.
  • Versions at or above the fixed releases listed above.

What is not known:

  • MongoDB 8.1 and 8.2. Neither branch appears in the affected list, and neither gets fixes any more. Version 8.1 support ended on 30 September 2025. Version 8.2 reached end of life on 31 July 2026, with 8.2.12 (28 July 2026) the last release. Whether they contain the bug has not been published.
  • MongoDB Atlas, MongoDB’s hosted cloud service. Whether it was affected, and whether MongoDB has already patched it, is not stated in the sources we could read.
  • Enterprise Edition. MongoDB’s notice “strongly recommend[s] that all Community Edition users upgrade”. Its position on Enterprise Edition is not in what we could retrieve.

How many installations are exposed has not been published.

MongoDB is more common behind custom web apps, booking systems and Node.js projects than behind a brochure website. If you are not sure what your site’s data lives in, the people who built it or host it will know in a minute.

If your site uses MongoDB and its database runs as a replica set, assume you are in scope until someone checks the version.

What can an attacker do?

Crash your database, and with it whatever depends on it: the app, the logins, the checkout. The CVE record adds that under certain conditions the same bug may let an attacker run code on the server with the database’s permissions. Public demonstrations so far show only the crash.

Three things make it worse:

  • No login needed. The CVE record says requests “that do not require authentication” can cause it. Datadog Security Labs, the researchers who analysed it, found that vulnerable servers accept the triggering request before login, so turning on authentication does not prevent it.
  • No interaction needed. Nobody on your side has to click anything or open anything. The scoring confirms no user action is required.
  • Network reach. Anyone who can connect to the database server over the network can attempt it. A database that can be reached from the internet is the worst case.

There are also things that make it harder, and they are worth knowing. The crash only happens if the targeted server later becomes the primary while it is still behind on recent changes. The attacker cannot make the server fall behind, cannot make it win the election, and cannot see when either happens. Datadog describes it as possible remotely and without a login, but only during a specific window the attacker cannot see. The requests sit waiting until the server restarts, rolls back or steps down from primary.

In practice that means an attacker can set the trap, but your own failover (a normal election, for example during maintenance or a server hiccup) is what springs it.

The score. MongoDB, as the CVE issuer, rated it 9.5 Critical under CVSS 4.0 and 9.0 Critical under CVSS 3.1. CVSS is the standard 0 to 10 scale for rating vulnerabilities. The two numbers are the same assessment in two versions of the scale, not a disagreement. Both mark it as hard to pull off, but with high impact on the confidentiality, integrity and availability of the server. NVD, the US government’s vulnerability database, has not given its own score; as of 12 November 2026 its record was still “Awaiting Analysis” and shows MongoDB’s scores only.

Is it being exploited?

No attacks have been reported. When it released the fix on 10 November 2026, MongoDB said it was “not aware of any attempts to take advantage of this vulnerability”. Ostorlab, a security company tracking it, said no attacks had been reported as of 13 November 2026.

That said, the work of figuring out how to trigger it has been done publicly:

  • Datadog Security Labs reproduced the crash in a lab, on MongoDB 8.0.34 in a four-member replica set, and published its analysis on 11 November 2026.
  • Proof-of-concept code (code that demonstrates a flaw) was published on GitHub on 11 November 2026.

Both demonstrate a crash. No public demonstration of code execution has been found.

CISA KEV: not listed. CISA is the US government’s cyber security agency, and its Known Exploited Vulnerabilities catalogue lists flaws with confirmed attacks. CVE-2026-118383 was absent from catalogue version 2026.11.10 and was still not listed as of 13 November 2026, the latest confirmation available to us.

For an Australian business, the practical reading is this. Nobody is known to be using it yet, so you have a head start. But the crash is now documented with working code, one day after the fix, and anyone who wants to knock a MongoDB database over has a starting point. A database outage is the kind of thing that turns into lost orders and a stressful afternoon. That is reason enough to update this week rather than at the next quarterly review.

What should you do now?

In this order:

  1. Find out whether you run an affected MongoDB. Ask whoever runs your database server three questions: do we use MongoDB, is it a replica set or sharded cluster, and which exact version is each server on? Compare the answer with the ranges above. If it is a single standalone server, this CVE does not apply.
  2. Update every replica set member to a fixed release. MongoDB says to upgrade as soon as possible, and Datadog stresses every member, not just the primary, because any of them can become primary. The latest releases on MongoDB’s Community Server download page today are 9.0.8, 8.3.17, 8.0.38, 7.0.48, 6.0.30, 5.0.35 and 4.4.32, all of which include the fix. Two details:
    • On RedHat/CentOS 8.1, 9 and 10 for ppc64le, and RedHat/CentOS 8.3 and 9 for s390x, there is no 9.0.7 build. Use 9.0.8.
    • If you are on 8.1 or 8.2, there is no fix coming for those branches. Moving to a supported branch is the route. As of 12 November 2026, only 9.0, 8.3, 8.0 and 7.0 are listed as supported. MongoDB did release fixes for 6.0, 5.0 and 4.4, but those branches are past support, so plan the move up as well.
  3. Check whether it has already been triggered. In plain terms, look in the database server’s logs for an unexpected crash right after the replica set elected a new primary. Datadog has published detection rules: a mongod segmentation fault (a type of crash) is treated as critical when the crash record contains CatchupState::abort_inlock, and another rule looks for a new primary that exits catch-up twice and then crashes. Datadog notes that a normal election, or a single catch-up exit, is not a sign of this CVE.
  4. If you find a matching crash, keep the logs, make sure every member is on a fixed release, and have someone who knows the server review it before assuming nothing else happened. Neither MongoDB nor the researchers have published guidance beyond updating, such as changing passwords or keys or restoring from backup. Because the CVE record does allow for code execution under certain conditions, a matching crash deserves a proper look, not just a restart.
  5. Record what you did. Write down each server’s version before and after, the date you updated, and what the log check found. If a client, insurer or auditor asks later, you will have the answer in one place.
  6. Reduce who can reach the database. Datadog says restricting network access reduces exposure while you upgrade. A database usually only needs to be reachable by the app that uses it. Do not rely on switching on authentication: on vulnerable versions it does not stop this.

If you can’t find the version, or you’d rather someone else checked, that’s what we do. Details at the bottom.

Why updating is not the whole fix

The fixed versions came out on 10 November 2026. Working crash code was public on 11 November. Today is 14 November. For any replica set still on an old version, that is four days in which the trap could have been set, and the request waits quietly until the next election springs it.

The update stops new attempts. It does not tell you whether a crash already happened in that window, which is why the log check in step 3 matters. It does nothing for servers on 8.1 or 8.2, which need a branch upgrade, not a patch. And it does not change who can connect to your database. If the database was reachable from the internet before, it still is afterwards, and the next database flaw will find it the same way.

There is also the question of who actually does this. A database server sits in an awkward spot. The host looks after the server, but usually not the software running on it. The people who built the site or app have other work on, and moved on to the next project once it launched. And nobody has been told, in writing, that the database updates are theirs. So a critical fix like this one lands in the gap between three parties who each reasonably think it belongs to someone else.

That is the pattern with most serious server-side vulnerabilities. The fix arrives quietly, the proof-of-concept arrives the next day, and the gap between the two is filled by whoever is actually watching the site.

What this looks like with BLACKBX

BLACKBX reads the exact software versions on every site it looks after each night, and checks new security advisories against them every hour. When a client’s site matches a critical advisory like CVE-2026-118383, our developers patch it immediately. Lower-severity items are done at the next service. Every update is dated and recorded in the client’s security logbook, so there is always a plain record of what changed and when.

On the Monitor plan, the finding goes to the client’s own developer with the version numbers and our advice, so the people who know the site can act on it straight away. On Maintenance and Full service, BLACKBX does the work. All plans are monthly, with no minimum term.

Timeline

Date Event
28 October 2026 CVE-2026-118383 reserved by MongoDB
10 November 2026 MongoDB announces the fix and releases 4.4.32, 5.0.35, 6.0.30, 7.0.48, 8.0.37, 8.3.16 and 9.0.7
10 November 2026 CISA KEV catalogue version 2026.11.10 released (19:03 UTC) without this CVE
10 November 2026 CVE record published (20:23 UTC)
11 November 2026 MongoDB forum posts announce 8.0.37 and 9.0.7
11 November 2026 MongoDB 9.0.8 and 8.3.17 released
11 November 2026 Datadog Security Labs publishes its analysis and crash reproduction; public proof-of-concept code appears on GitHub
12 November 2026 The Hacker News reports the flaw; NVD record still “Awaiting Analysis”
12 November 2026 MongoDB 8.0.38 posted on the MongoDB forum (approximate date)
13 November 2026 Still not in CISA KEV; no attacks reported
14 November 2026 This article published

Sources

Common questions

What is CVE-2026-118383?

CVE-2026-118383 is a critical use-after-free memory bug in MongoDB Server’s replication component. Requests that need no login can leave a replica set member set up to crash when it is next elected primary while behind on changes, and under certain conditions it may allow code to run on the server. MongoDB fixed it on 10 November 2026. BLACKBX checks the exact versions on the sites it looks after against advisories like this one every hour, and patches critical matches immediately.

Is CVE-2026-118383 being exploited?

No attacks using CVE-2026-118383 had been reported as of 13 November 2026, and it was not in CISA’s Known Exploited Vulnerabilities catalogue at that date. However, Datadog Security Labs reproduced the crash and proof-of-concept code was published on GitHub on 11 November 2026. BLACKBX treats a critical flaw with public crash code as something to patch now, not later.

Does turning on MongoDB authentication protect against CVE-2026-118383?

No. Datadog Security Labs found that vulnerable MongoDB servers accept the triggering request before login, so authentication does not prevent CVE-2026-118383. The fix is updating every replica set member to a fixed release, and restricting network access to the database helps while you do. On BLACKBX’s Maintenance and Full service plans, we do that update and record it in your security logbook.

Which MongoDB versions fix CVE-2026-118383?

CVE-2026-118383 is fixed in MongoDB 4.4.32, 5.0.35, 6.0.30, 7.0.48, 8.0.37, 8.3.16 and 9.0.7, released on 10 November 2026. The latest releases today are 9.0.8, 8.3.17, 8.0.38, 7.0.48, 6.0.30, 5.0.35 and 4.4.32. Versions 8.1 and 8.2 are end of life and get no fix, so they need a move to a supported branch. BLACKBX reads each site’s exact versions nightly, so we know which of these applies.

Is a standalone MongoDB server affected by CVE-2026-118383?

No. CVE-2026-118383 only affects replica set members, including the shard and config server members of sharded clusters. A standalone mongod never does primary catch-up, so it does not reach the faulty code. If you are not sure which setup you have, BLACKBX can check it and tell you plainly whether this applies.

Is MongoDB Atlas affected by CVE-2026-118383?

MongoDB’s published material that we could read does not say whether its hosted Atlas service was affected by CVE-2026-118383 or whether MongoDB has already patched it. If your database is on Atlas, check MongoDB’s notice or ask your account contact. For self-run MongoDB, BLACKBX matches the exact installed version against the advisory and handles the update.

Is this your site?

Does CVE-2026-118383 affect your website or app?

Tell us about your site and we’ll tell you whether CVE-2026-118383 applies, based on the exact MongoDB version and setup it runs. If it does, our developers will update it and record the work in your security logbook.

Ask us if this applies to you Get these alerts by email

Or call +61 2 9043 1246. Monthly plans, no minimum term.