MongoDB Patches Critical Pre

MongoDB has shipped fixed releases for a critical vulnerability in MongoDB Server that lets an unauthenticated client plant two requests and later crash a replica set member as it takes over as primary, the company disclosed on Nov. 11. The flaw is tracked as CVE-2026-118383 and carries a CVSS 4.0 base score of 9.5, the highest severity tier, with a 9.0 rating under CVSS 3.1.

The company said its own security program found the issue and that it is "not aware of any attempts to take advantage of this vulnerability." It said the fix is unrelated to recent industry vulnerabilities and security incidents. MongoDB urged users of the free Community Edition to move to a patched release as soon as possible.

The bug is a use-after-free, meaning the server ends up referencing memory it has already released. According to a technical analysis by Datadog Security Labs, which reproduced the crash in a lab and published its findings on Nov. 11, the defect sits in the cleanup routine that runs when a member finishes catching up after winning an election.

A replica set is a group of MongoDB servers holding copies of the same data. One member, the primary, handles all new writes while the others replicate them; if the primary goes away, the remaining members hold an election to choose a replacement. A member that wins an election first applies the writes it missed before accepting new ones.

The two requests are ping commands carrying a readConcern.afterOpTime value. Each asks the server to wait until replication reaches a specified point, and the server records a pending notification, known as a waiter. Planting the waiters alone does no harm: they do not expire and persist until the member restarts, rolls back or steps down from primary.

The crash requires the member that received the requests to later win an election even though it trails another member. When catch-up ends, the cleanup runs twice and reuses memory that was already freed, and the new primary crashes before accepting any writes. Once those conditions are met, the researchers said, the crash does not depend on winning a timing race.

In the lab, the team used administrative access to pause and stop mongod processes to make the target member fall behind and to force a failover; only the two requests came from a client without credentials, and that client could not write to the database. On version 8.0.34, the member crashed with a segmentation fault, leaving the lab cluster without a primary. In the fixed 8.0.37, both requests were rejected as unauthorized immediately and the member kept running.

Enabling authentication does not block the two requests on vulnerable versions. The researchers also noted that an attacker cannot force the targeted member to fall behind, cannot make it win an election, and cannot observe when either event occurs. MongoDB said the flaw may also allow arbitrary code execution in the server process under certain conditions, though the researchers said "we did not achieve code execution" in the lab and their results do not establish how often the attack would succeed in other deployments.

A proof of concept published on GitHub reports that 8.2.12 still showed the bug in a lab test using a test-only setting that a remote attacker cannot enable; its stated impact is a crash or memory corruption, with no claim of code execution. The 8.2 branch is not among the affected versions listed and reached end of life on July 31 under the company's lifecycle schedule, after which a version no longer receives fixes, including security fixes.

Fixed releases by branch:

Note: every earlier release in each affected branch is vulnerable, back to the branch's first release. The affected population includes shard and config server members of sharded clusters; a standalone mongod outside any replica set is not affected.

MongoDB Atlas clusters receive fixed versions automatically during maintenance, and customers who defer maintenance are being asked to pull the upgrade forward. Self-managed deployments need the fixed release on every replica set member, and operators should confirm the version each member is running after upgrading, including members in containers and any that were offline during maintenance.

Until a member can be upgraded, the researchers advise restricting network access to the database to only the systems that need it. That narrows who can send the two requests but does not remove the flaw. One part of the fix limits readConcern.afterOpTime to system users; the second stops the cleanup from running twice even when waiters are already in place, a component the researchers said they did not test themselves.

For detection, the researchers pointed to three signs in the server's structured logs from their vulnerable run: a COMMAND "Slow query" entry (event ID 51803) for an unauthenticated ping carrying readConcern.afterOpTime that ended with MaxTimeMSExpired; a member entering primary catch-up (ID 21359) and then exiting it twice (ID 21363) within a single transition; and a fatal signal or backtrace involving CatchupState::abort_inlock() after those exits. A normal election or a single catch-up exit does not indicate this flaw, and because the requests may arrive before the failover, earlier logs from the same member should also be reviewed. Whether the request fields are logged depends on logging settings, and the attr.remote field may show a loopback address rather than the client's real IP.

The severity rating puts the issue in urgent-patch territory for any organization running self-managed replica sets, particularly those on branches that have already lost vendor support. Operators running sharded clusters face the widest exposure because shard and config server members are in scope. The practical exposure hinges on network reachability: an attacker needs a path to the database port to plant the waiters, so perimeter controls buy time, but they do not substitute for upgrading every member.