Research

MongoDB CVE-2026-118383 (9.5): Two Unauthenticated Pings Can Crash a Replica Set's New Primary. Upgrade, Turn On Authorization, and Get Off 8.2

Patrick Duggan · · 5 min read

MongoDB CVE-2026-118383 (9.5): Two Unauthenticated Pings Can Crash a Replica Set's New Primary. Upgrade, Turn On Authorization, and Get Off 8.2

If you run a MongoDB replica set yourself, upgrade every member to a fixed release for its branch: 9.0.7, 8.3.16, 8.0.37, 7.0.48, 6.0.30, 5.0.35 or 4.4.32. That includes the shard and config server replica sets of a sharded cluster. Standalone mongod instances are not affected. While you schedule the upgrade, make sure port 27017 is reachable only from the application servers and other members that need it. If any deployment runs with authorization turned off, turn it on. And if you are on 8.2, move to 8.3.16 or 9.0.7, because 8.2 reached end of life on July 31 and MongoDB lists no fix for it.

If you use MongoDB Atlas, MongoDB says clusters "are upgraded automatically to fixed versions during cluster maintenance". If you are deferring maintenance, MongoDB recommends applying the upgrade as soon as possible, and so do we.

What MongoDB confirmed

CVE-2026-118383 was published on Tuesday, November 10. The CVE record, which MongoDB filed as the CNA, describes it as a use-after-free in the replication component that "can occur when a newly elected replica set primary completes catch-up". It goes on: "The condition can be caused by requests that do not require authentication, and may result in the server terminating unexpectedly or, under certain conditions, arbitrary code execution in the context of the server process."

The score is 9.5 on CVSS 4.0, with vector AV:N/AC:H/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H. That means network-reachable, no privileges and no user interaction, but high attack complexity. The complexity is real, and we explain it below.

The affected ranges, identical in the CVE record and on MongoDB's security alerts page, are 9.0.0 before 9.0.7, 8.3.0 before 8.3.16, 8.0.0 before 8.0.37, 7.0.0 before 7.0.48, 6.0.0 before 6.0.30, 5.0.0 before 5.0.35 and 4.4.0 before 4.4.32. MongoDB's forum announcement says it found the flaw "internally through our proactive security program", offers no workaround, and says "we are not aware of any attempts to take advantage of this vulnerability." The flaw is not in CISA's Known Exploited Vulnerabilities catalog as of the November 13 catalog release.

How the crash works, according to the public proof of concept

A proof of concept was published on GitHub on November 11 by the account googlesky. It includes a lab that compares a vulnerable build with a fixed one. We read its README. We did not run it.

The flaw is reachable through readConcern.afterOpTime, an old command option that vulnerable builds accepted from any connection, before any login, even on commands like ping. The author shows that two such pings with crafted values plant "waiters" on a secondary that the server can never satisfy. If that secondary is later elected primary while it is still behind, the end of its catch-up phase frees an object that is still in use. The release build often survives this silently. When it does not, the new primary crashes, before it has accepted any writes.

That is why the complexity is high. The pings are easy, but the crash also needs an election that a lagging member wins. The author's reliable mode turns on a test-only server setting to hold that member behind. The mode without it is timing-dependent, and the author says that on a fast disk the member can catch up first. In that lab, 8.0.34 and 8.2.12 crashed and 8.0.37 did not. The author reports no code execution. The CVE record still says code execution is possible "under certain conditions", so treat it as possible.

Why turning on authorization matters here

MongoDB's fix has two parts, according to the proof of concept author's reading of the commits. One part repairs the use-after-free itself. The other rejects afterOpTime from clients that lack internal cluster privileges.

The author notes a catch. With authorization disabled, every client effectively holds those privileges, so even the fixed 8.0.37 accepts the unauthenticated pings. In the author's lab the crash still did not happen on 8.0.37, because the first part of the fix held. So upgrading closes the crash either way. But a deployment with authorization off still lets anyone plant those waiters, and anyone who can reach it can already read your data. Turn authorization on.

What to check after you upgrade

The proof of concept gives a fingerprint for the double abort that causes the crash: in serverStatus, numCatchUpsSucceeded and numCatchUpsAlreadyCaughtUp both go up by one in the same catch-up, and the log shows two "Exited primary catch-up mode" lines with the same timestamp. A fixed build shows only the numCatchUpsAlreadyCaughtUp increase and a single exit line. If you see the double pattern on a member that crashed or was elected unexpectedly since November 10, look at what was connecting to it.

Also check the version on every member, not just the primary. The crash happens on whichever member wins the next election.

What we did not verify

  • We did not run the proof of concept or test any version ourselves.
  • MongoDB lists fixed builds for 6.0, 5.0 and 4.4, which its own lifecycle page shows as past end of life. We did not check who can download those builds.
  • MongoDB's affected list does not include 8.2, but the proof of concept reproduced the crash on 8.2.12. We take MongoDB's lifecycle page at its word that 8.2 is no longer supported, and our advice is to leave it.
  • The Hacker News reports that Datadog Security Labs reproduced the crash. We did not read Datadog's writeup.

How we know

We read the CVE record JSON from the CVE Services API, MongoDB's security alerts page, MongoDB's community forum announcement of November 10, the SERVER-138119 ticket in MongoDB's Jira (its fix versions match the CVE's fixed releases, though the ticket does not name the CVE), MongoDB's product lifecycle page, the CISA KEV JSON feed (catalog release of November 13), and the googlesky/CVE-2026-118383 README, all on November 15. The Hacker News article of November 12 led us to the story.

Our exploit harvester picked up the googlesky repository on November 11 at 06:01 UTC, about ten hours after the CVE was published. That is when a public exploit appeared, not a sighting of attacks. Our edge instruments watch HTTP traffic to web properties, and this flaw is in the MongoDB wire protocol, so our edge would not see an attempt. We make no claim either way about whether anyone is trying it.

None of the sources we read published network indicators, so we added nothing to the feed for this one.

Sources

If this was useful, or if it wasn't, the rating widget below takes ten seconds and is the only way we know.

Every indicator in this post is in the feed. Free.

1.58M+ IOCs, STIX 2.1 / TAXII, 88% novel vs ThreatFox, exploited-CVE leads ahead of CISA. No credit card — a free API key in 30 seconds, and you can audit every claim above against the live endpoints.

Get your free key → analytics.dugganusa.com/stix/register