MongoDB, critical CVE-2026-118383 flaw and 26 patches

MongoDB has released updates for 26 vulnerabilities in MongoDB Server, 2 critical and 16 high, and the ACN reported them on November 11, 2026. The most discussed is CVE-2026-118383, rated 9.5 out of 10, which allows anyone without credentials to bring down a server in a replica set. It matters to anyone who runs databases on their own, because in these cases the update is up to you.

A few terms before we get into the facts. Replica set is a group of MongoDB servers that keep copies of the same data. The primary is the main server that receives writes, and if it goes missing the others vote in a new primary through an election. Failover is the handover of that role. A use-after-free is an error where a program uses memory that has already been released. CVSS is the severity scale from 0 to 10.

What did MongoDB fix?

According to the ACN alert , the updates patch 26 vulnerabilities. The types range from arbitrary code execution to authentication bypass, from privilege escalation to information disclosure, up to denial of service.

The ACN recommends updating by following the vendor's bulletins. The alert lists only the critical and high severity CVEs.

Which versions are affected?

Seven branches of MongoDB Server are affected, and they must be brought to at least these versions.

9.0.x, to be updated to 9.0.7

According to The Hacker News , every earlier version in the branch is affected, back to the first one. A single mongod, outside a replica set, is not affected.

How does the CVE-2026-118383 flaw work?

The attacker sends two ping commands with a readConcern.afterOpTime value. The server records two pending notifications, the waiters, which remain until a restart, a rollback or the handover of the primary role. They do not cause an immediate crash.

The crash comes if that member wins an election while lagging behind others. Once recovery ends, cleanup runs twice on the same memory and the new primary crashes before accepting writes. According to the Datadog Security Labs researchers, enabling authentication does not stop the two requests on vulnerable versions.

How to tell if you were hit and what to do?

In structured logs, look for an unauthenticated ping with readConcern.afterOpTime ending in MaxTimeMSExpired, a member entering catch-up (ID 21359) and exiting twice (ID 21363), and a fatal signal tied to CatchupState – – abort_inlock().

MongoDB says it knows of no exploitation attempts. Datadog's work is a laboratory test. The researchers did not achieve code execution, although MongoDB considers it possible under certain conditions, and they do not know how often the attack would succeed in other settings. The second part of the fix was not tested by them. A proof of concept reports the bug on 8.2.12, a branch not listed, but with a test configuration.

What changes for those who work with digital systems

If you use MongoDB in a replica set, including as a shard or config server, you have an inventory to do. Check the version of every member, including those in containers, and plan the update. If you cannot do it right away, limit network access to the database to only the systems that need it, a measure that reduces who can send the requests but does not fix the flaw. If you run an 8.2 branch, know that it has been end of life since July 31 and no longer receives fixes. For the basics of MongoDB, our pillar guide remains useful.

The flaw does not allow data theft, but a database that crashes exactly at failover is a serious problem, because failover exists to guarantee continuity. It is striking that authentication is not enough. The weak point is a network port left open more than necessary. This happens often, as other cases such as the Railway breach show. On a database the network should be closed on principle, not only after a warning.

Frequently asked questions

Does CVE-2026-118383 affect a single MongoDB instance?

No. A standalone mongod, outside a replica set, is not affected. Members of replica sets are, including shards and config servers of sharded clusters.

Do you need to authenticate to exploit it?

No. The two requests come from a client without credentials, and according to the researchers, enabling authentication on the vulnerable versions does not block them.

9.5 out of 10 on the CVSS 4.0 scale, a rating given by MongoDB itself. The company says it found the flaw on its own.

Do Atlas users need to do anything?

Usually not, because Atlas receives the fixed versions during maintenance. Those who postpone maintenance should apply the update as soon as possible.

What can I do if I cannot update right away?

Limit network access to the database to only the systems that need it. This does not fix the flaw, but it reduces who can send the two requests.

What to check in the coming days on your replica sets

The fix exists, but security depends on how quickly it reaches every member. Open questions remain real-world exploitation and the 8.2 branch.

Check whether news of real exploitation of CVE-2026-118383 appears, as happened with WordPress .

Review member logs even before failovers, because the requests may arrive well before the crash.

If you run 8.2, plan the move to a supported branch.

acn.gov.it, Risolte vulnerabilità in MongoDB Server

thehackernews.com, Critical Pre-Auth MongoDB Flaw (CVE-2026-118383) Can Crash Lagging Servers on Failover

Gemini Decisions API, Google launches an endpoint for a thousand decisions in one call

Google introduces the Gemini Decisions API and the Gemini Decision 1 model. Up to a thousand questions on one multimodal...

Gmail, Gemini reaches all adult Workspace users with AI Overview and Help me write

Google brings AI Overview and non-personalized Help me write to all Workspace users aged 18 and over, on by default. Wha...

Fake INPS site via SMS, CERT-AgID uncovers a fake Android APK

CERT-AgID has uncovered a fake INPS site spread via SMS that urges users to download an Android APK. The file is still e...