MongoDB CVE-2026-118383: Patch Before the Next Failover

MongoDB CVE-2026-118383 is a critical unauthenticated use-after-free in MongoDB Server. Two requests that need no login can plant a condition that later crashes a replica set member during failover. If your site, shop, or login depends on that database, a clean homepage does not mean the cluster behind it is safe.

What is MongoDB CVE-2026-118383?

MongoDB CVE-2026-118383 is a critical flaw in MongoDB Server. Someone with no account can send two requests that plant a condition for a later crash. MongoDB scored it 9.5 out of 10 on CVSS 4.0. The bug is a use-after-free: the server uses memory it has already freed.

MongoDB says it found the flaw itself and is "not aware of any attempts to take advantage of this vulnerability." The Hacker News report is dated November 12, 2026, and it places the Datadog Security Labs write-up on the day before that dateline. The reporting names no threat actor and describes no theft of data.

The vendor says the flaw may result in arbitrary code execution in the server process under certain conditions. Datadog’s researchers wrote, "we did not achieve code execution." In their lab the outcome was a crash. Treat code execution as a vendor warning, not as a demonstrated result.

A proof of concept on GitHub, according to its author, reproduces the bug in a lab replica set. Reliable mode needs a test-only setting a remote attacker cannot enable. The stated impact is a crash or memory corruption, with no claim of code execution. That proof of concept is the source of the 8.2.12 lab note below.

The two requests do nothing obvious when they arrive. The member dies later, and only if it wins an election while it still lags another member. For a shop, login, or app on MongoDB, that is an outage on a failover you did not schedule. A status page does not read the mongod version string or show a secondary that was offline when the rest of the set was upgraded.

How two unauthenticated requests can kill a primary

CVE-2026-118383 can take down a new primary, but the two requests do not crash the server when they arrive. An unauthenticated attacker sends two ping commands that carry a readConcern.afterOpTime value. Each asks the member to wait until replication reaches a given point. The server records a pending notification called a waiter.

On a vulnerable build, Datadog found that enabling authentication did not stop those two requests. In the lab, that client had no credentials and could not write to the database. The researchers used separate admin access to pause and stop mongod processes so a member fell behind and the set failed over.

Planting the waiters does not take the member down. The waiters do not expire. They stay until that member restarts, rolls back, or steps down from primary. Pages can keep loading for hours or days with the condition still in place.

The member that received the requests must later win an election while it is still behind another member. A winner first catches up by applying missed writes before it accepts new ones. The flaw sits in the cleanup at the end of that catch-up. On vulnerable code the cleanup runs twice and reuses memory that was already freed. The new primary dies before it accepts any writes. Once those conditions are met, the researchers say the crash does not depend on a timing race.

The attacker cannot force the lag, cannot force the election win, and cannot see whether either happened. From outside, you cannot prove the bug is absent in a live cluster by trying it. A failed attempt rules nothing out.

The Datadog lab produced a segmentation fault on version 8.0.34 and left that cluster with no primary. Another deployment might elect a new primary and keep running. What 8.0.37 did in the same lab is in the version section.

The primary handles new writes. The other members replicate them. If the primary disappears, the members elect a replacement. If that new primary then dies in catch-up, the set can have no writable primary until another election finishes. The proven lab impact is availability: the process crashes, writes stop, and nobody has to copy a table of customer rows for the shop to stop taking orders.

On a vulnerable build, the next ordinary failover is when that risk turns into an outage. A planned step-down, a dead host, or a maintenance election can hit waiters planted earlier. You do not get a warning when the two pings land.

Who is affected, and who is not?

Replica set members are affected, including shard servers and config servers in a sharded cluster. A standalone mongod outside any replica set is not affected. Patching only the current primary still leaves the set exposed. Every earlier release in an affected branch is vulnerable, back to that branch’s first release. MongoDB shipped fixed builds for each affected branch earlier in the week of the November 12, 2026 report.

Those fixed release numbers live in the CVE record and in MongoDB’s security announcement. This article cites only one numbered pair from the lab: 8.0.34 and 8.0.37. Match your own branch to the advisory. Do not copy 8.0.37 onto another major line and treat it as the fix.

On vulnerable versions, turning authentication on did not block the two requests in the Datadog lab. A network limit still matters until you upgrade, because only a host that can reach the database port can send the pings. The limit does not repair the memory bug.

Sharded clusters add members that are easy to skip. Patching the shard that holds the app database and skipping the config servers leaves another replica set on the path. The member that receives the requests does not have to be primary then. It has to win later, while lagging. Leaving one old voting member keeps the crash path. Upgrade every member that can be elected.

The person who edits the public site is often not the person who runs the replica set. Ask for the build string on each mongod, including secondaries and config servers, and count members that were down during the last change.

Which MongoDB version should you be running?

Run the fixed release MongoDB published for your branch. The only pair cited by number from the lab is 8.0.34, which is vulnerable, and 8.0.37, which is fixed. On 8.0.34 the member died with a segmentation fault and the cluster lost its primary. On 8.0.37 the server rejected both requests as unauthorized at once and kept running. Check the exact build, not the major version.

The fix has two parts. One part lets only system users use readConcern.afterOpTime. The second part stops the catch-up cleanup from running twice even when waiters are already present. Datadog did not test that second part. In a proof-of-concept run with authentication turned off, fixed 8.0.37 accepted the planted waiters and ran the cleanup only once. The report that 8.0.37 rejected both requests as unauthorized is a separate result. The write-up does not say authentication was enabled for that rejection test. Install the vendor build, which contains both parts of the fix.

Fixed builds for the affected branches went out in the same week as the November 12, 2026 report. The write-up does not give a separate calendar date for each branch. Use the advisory for the number that matches your branch.

The 8.2 line is separate, and the evidence is weaker. It is not in the affected list in the reporting. The newest 8.2 release named there is 8.2.12. A GitHub proof of concept reported that 8.2.12 still showed the bug in a lab, and only with a test-only setting a remote attacker cannot enable. The 8.2 branch reached end of life on July 31, per MongoDB’s lifecycle schedule. The reporting does not state the year. Past that date the branch receives no further fixes, including security fixes. If you are on 8.2.12, migrate to a supported branch that MongoDB lists as fixed. Do not wait for an 8.2 backport.

Restarting a secondary does not by itself start an election. An election starts when the current primary is restarted or stepped down. On a vulnerable build, that election is when a planted waiter can fire if the lagging member wins. Do not restart members one by one to see whether the crash happens.

What if MongoDB Atlas or your host runs the database?

MongoDB Atlas clusters receive fixed versions automatically during maintenance. Customers who deferred maintenance should apply the upgrade as soon as possible. If you deferred the window, assume the old build is still running until maintenance finishes and you confirm the version. Being on Atlas is not the same as being patched. Confirm versions after maintenance, not from the announcement. A member that missed the window can come back on the previous build and remain eligible for election, including members that were offline and members in containers.

Self-managed deployments are where you apply the build yourself: virtual machines, containers, and hosts a panel starts. Every replica set member needs the fixed release. One old secondary is enough to keep the crash path, because the set can elect it later. A down host or a secondary in another region can rejoin on the old binary. A pinned image tag such as mongo:8.0.34 will not move because another service was rebuilt. Read the version from the running server after the container starts.

Until you can upgrade, restrict network access to the database so only the systems that need it can connect. The Datadog researchers advise that step. It limits who can send the two requests. It does not remove the flaw. Test the limit from a host that should be refused.

If a provider runs MongoDB and you cannot query it yourself, ask for the version string on each member, whether it is a replica set or a standalone, and whether maintenance was deferred. Also see whether the driver points at a public address. A public database port is a finding on its own. Our article on what to ask your host when only they can patch is the same ownership problem on a different CVE. Send those three questions in one ticket.

How do you check MongoDB logs after a failover?

If writes are failing right now

• Run rs.status() and record which member was primary.
• Identify the member that crashed and keep its logs.
• Check whether a majority of voting members is still reachable.
• Restore writes only on a member whose build you have confirmed.
• Patch every other member before the next election.

Look for three log signals together. A normal election is not proof of this bug. Datadog’s notes use MongoDB structured logs and stable message IDs. One signal without the other two is not enough to name CVE-2026-118383.

First, look for a COMMAND "Slow query" entry, ID 51803, for an unauthenticated ping carrying readConcern.afterOpTime that ended with MaxTimeMSExpired. That is the planting line from the researchers’ vulnerable run. The requests may arrive long before any failover, so search earlier logs from the same member.

Second, in one transition, the member enters primary catch-up (ID 21359) and exits catch-up twice (ID 21363). One exit can be a normal election. Two exits in the same transition match the double cleanup. A single exit does not point to this flaw.

Third, look for a fatal signal or backtrace involving CatchupState::abort_inlock() after those exits. That is the lab crash signature. It is not the same thing as a process manager reporting that mongod restarted.

The attr.remote field may show a loopback address instead of the client IP, so 127.0.0.1 does not prove the ping came from the database host. The two requests can land long before the election, so the crash line alone looks like an unexplained segfault during catch-up. Save the lines with timestamps and the member name. A crash on one host and a slow ping on another are not the same event. The pattern Datadog described is on the member that received the pings and later won.

A clean search is not a clean bill of health. If slow-query logging was off, ID 51803 was never written. A routine restart clears waiters, so a later election can look normal. Keep older logs until every member’s upgrade is confirmed. A healthy election has one catch-up exit and no fatal signal. Do not replay the requests on production to test the bug.

What should you verify before the next election?

Verify the running version on every member, upgrade each affected member to the fixed build for its branch, and restrict the database port until that work is finished. Start with a list, not a restart. A claim that you are on 8 is not a build number. The advisory, not this article, is the list of fixed releases per branch.

• On each member, record the version with db.version() and rs.status(), or your operator’s equivalent. Include secondaries, config servers, shard members, and containers that were stopped.
• Match the list to MongoDB’s fixed releases for your branch. In the lab pair, 8.0.34 is vulnerable and 8.0.37 is fixed.
• On Atlas, if you deferred maintenance, schedule it and confirm the version after the window, including members that were offline.
• On 8.2, including 8.2.12, treat the branch as end of life since July 31 and move to a supported fixed line. The reporting does not state the year. Do not wait for an 8.2 security release.
• Until the new build is running, allow the database port only from application hosts that need it, and test the block from a host that should fail.
• After the upgrade, confirm the process or image tag changed. A pinned mongo:8.0.34 tag survives a pipeline that only rebuilds another service.
• If a primary already crashed, keep logs from before the failover and look for IDs 51803, 21359, and 21363 plus CatchupState::abort_inlock().

Enabling authentication remains the right control for a database that still has no users. It does not close CVE-2026-118383 on a vulnerable build. If a member was offline, patch it before it rejoins and can win an election. If the primary already died, restore writes on a member you have confirmed is fixed, and keep the crashed member’s logs. A restart clears waiters. The new build is what stops the next election from repeating the crash.

Owners who are not sure the site even uses a replica set can start with the website security FAQ and the version questions above. The database check is separate from a file scan of the public site. If you also want monitoring on the site itself, see website protection after the cluster versions are confirmed.

FAQ

What is CVE-2026-118383 in MongoDB Server?

It is a critical use-after-free, scored 9.5 on CVSS 4.0, in MongoDB Server replica set members. Two unauthenticated ping commands that carry readConcern.afterOpTime plant waiters that can crash a lagging member if it later wins an election, when catch-up cleanup runs twice.

Is CVE-2026-118383 being exploited?

MongoDB says it found the flaw and is not aware of any attempts to take advantage of it. Datadog Security Labs published a lab reproduction the day before The Hacker News report dated November 12, 2026, with no named incident, victim, or threat actor.

Does MongoDB authentication stop CVE-2026-118383?

Not on a vulnerable build. Datadog found that enabling authentication did not stop the two requests. On fixed 8.0.37 the server rejected both requests as unauthorized, and the write-up does not say authentication was on for that test. One part of the fix limits readConcern.afterOpTime to system users.

Which MongoDB versions fix CVE-2026-118383?

MongoDB released a fixed build for each affected branch earlier in the week of the November 12, 2026 report. Every earlier release in an affected branch is vulnerable back to that branch's first release. The only lab pair named here is 8.0.34 vulnerable and 8.0.37 fixed. Use the advisory for your branch.

If the site in front of this database was left exposed while you sort the cluster, start with a protection package and keep the MongoDB upgrade on its own checklist until every member reports a fixed build.