MongoDB Fixes CVE-2026-118383, Which It Scored 9.5: Datadog Crashed a Lab Replica Set Primary With Unauthenticated Requests and a Forced Failover

Overview

MongoDB published CVE-2026-118383 on 2026-11-10; its CVE record shows a publication time of 20:23 UTC, and MongoDB is the record’s CVE numbering authority. The record describes a use-after-free “in the replication component of MongoDB Server” that “can occur when a newly elected replica set primary completes catch-up”. It says 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.” MongoDB, as the numbering authority, gave it a CVSS 4.0 base score of 9.5 and a CVSS 3.1 base score of 9.0, both labelled Critical (CVE record).

Researchers at Datadog Security Labs reproduced a crash in a lab on 8.0.34 and wrote that “we did not achieve code execution” (Datadog).

Affected and fixed versions

The CVE record lists seven branches, each affected from its first release (x.0.0) up to, but not including, a fixed release: 9.0.7, 8.3.16, 8.0.37, 7.0.48, 6.0.30, 5.0.35 and 4.4.32. Datadog lists the same seven fixed releases. Replica set members are affected, including the shard and config server members of sharded clusters; standalone mongod instances are not (CVE record).

When the Herald read it on 2026-11-13 at 09:20 UTC, the NVD entry (last modified 2026-11-10 at 22:08 UTC) showed the status “Awaiting Analysis” and carried only the two scores supplied by MongoDB. The GitHub advisory is marked “unreviewed”.

What the attack needs, according to the sources

Datadog writes that “Remote unauthenticated exploitation is possible, but only during a specific window that the attacker does not have visibility into” (Datadog). In its account, an unauthenticated client sends two ping requests that carry a readConcern.afterOpTime value. Each leaves a pending notification, which Datadog calls a waiter, on a replica set member, and the waiters stay until the member restarts, rolls back or steps down from primary. The crash follows only if that same member later wins an election while behind another member, and Datadog adds that “The attacker can’t cause the lag or the election” (Datadog). The Hacker News puts the condition this way: “The crash occurs only if that server is later chosen to take over as the main server while it still lacks some recent changes.” Datadog and The Hacker News both say that turning on authentication does not stop the two requests on vulnerable versions (Datadog; The Hacker News).

Datadog built a four-member replica set in its lab and used admin access to pause and stop mongod processes, creating the lag and the failover itself (Datadog). On 8.0.34 with the two requests sent, the member exited catch-up twice, logged SIGSEGV and crashed, and the test cluster was left with no primary. On 8.0.34 with no requests, the member remained running. On 8.0.37 the two requests were “rejected immediately with Unauthorized”, and the member remained running (Datadog). Datadog says its results “don’t tell us how often it would succeed in other topologies” and that another deployment “might elect a new primary and keep running” (Datadog). Datadog’s page also describes how its own Cloud Security Management and Cloud SIEM products detect this CVE (Datadog).

The fix, and where the sources differ

A public proof-of-concept repository, googlesky/CVE-2026-118383, says two server fixes shipped in 8.0.37. One, SERVER-138175, changes how the catch-up state is held. The other, SERVER-138119, rejects a client-supplied readConcern.afterOpTime unless the client holds the internal action type. The same README says that with authorization disabled, 8.0.37 still accepts afterOpTime, so the rejection can be observed only on an auth-enabled deployment (PoC README). The Hacker News says the proof-of-concept lab test, run with authentication off, showed the fixed 8.0.37 accepting the planted waiters but running the cleanup only once. Datadog says its 8.0.37 run did not test the half of the fix that stops a double cleanup when waiters are already in place (Datadog).

The 8.2 branch is where the sources diverge. The CVE record lists no 8.2 versions. The README’s header row lists “8.2 builds before the backport (8.2.12 tested)”, and its results table records a double abort on 8.2.12, which it describes as the newest 8.2 image at test time (PoC README). The Hacker News says that, according to MongoDB’s lifecycle schedule, 8.2 reached end of life on July 31. The README says the test-only setting used in that run cannot be enabled by a remote attacker (PoC README). None of the cited sources lists a fixed 8.2 release.

Exploitation, credit and related records

Per The Hacker News, MongoDB said it found the flaw itself and was “not aware of any attempts to take advantage of this vulnerability”; Datadog adds that this was MongoDB’s position “at the time of its announcement” (Datadog). None of the cited sources reports exploitation in the wild, and CISA’s Known Exploited Vulnerabilities catalog data, read on 2026-11-13 at 09:28 UTC (catalog version 2026.11.10, released 2026-11-10 at 19:03 UTC), does not list CVE-2026-118383 (CISA). In order: the CVE record was published on 2026-11-10 at 20:23 UTC; Datadog’s article and the proof-of-concept repository both date from November 11, the repository’s creation time being 05:59 UTC according to GitHub’s API and the Datadog page showing no time (Datadog; PoC repository); and The Hacker News article is dated November 12 (The Hacker News).

The CVE record marks discovery as internal and has no credits field (CVE record); the GitHub advisory’s credits list is empty (GitHub advisory). None of the cited sources names an outside reporter of the flaw.

CVE-2026-120828, published the same day at 20:23 UTC, describes wait records that a node does not limit or reclaim when a client-supplied read option names a point in time the node will never reach; it says a party with network access and no credentials can cause this, “which may make the server run out of memory and become unavailable”. Its only reference is SERVER-138119, one of the two tickets referenced by CVE-2026-118383, and it lists the same seven branches and fixed releases (CVE record). MongoDB scored it 8.7 on CVSS 4.0 (NVD entry). Neither Datadog nor The Hacker News mentions it.

By the Herald’s own count, an NVD query for records from MongoDB’s numbering authority published between 2026-11-09 and 2026-11-12, run on 2026-11-13 at 09:29 UTC, returned 26 records. CVE-2026-118383 has the highest CVSS 4.0 score of the 26, and it and CVE-2026-120828 are the only two that list the 6.0, 5.0 and 4.4 branches. Neither tally is a figure stated by MongoDB or the cited outlets.