MongoDB CVE-2026-9753: Brief Summary of the $_internalApplyOplogUpdate Out-of-Bounds Memory Read

Introduction

A malformed binary diff fed into MongoDB Server's $_internalApplyOplogUpdate aggregation pipeline stage can leak heap memory or crash the database process, and any authenticated user with access to the aggregate command can trigger it. More than 55,000 organizations run MongoDB worldwide, and recent MongoDB bugs have been exploited quickly after disclosure (MongoBleed most notably). Teams managing MongoDB deployments should give this one immediate attention.

Technical information

The vulnerable component

CVE-2026-9753 targets the $_internalApplyOplogUpdate aggregation pipeline stage in MongoDB Server. This internal stage processes document diffs as part of oplog (operations log) replication. In normal operation, it applies structured diffs to documents to replicate changes across replica set members.

The stage does not properly validate that binary diff inputs match the expected type and structure. When it receives a document diff that contains a malformed binary diff, the server processes it without adequate bounds checking or type verification. The result is one of two outcomes. Either the server reads memory outside the intended buffer boundaries (an out-of-bounds read), or it crashes entirely.

Root cause: CWE-1287

The root cause is classified under CWE-1287: Improper Validation of Specified Type of Input. MITRE defines this as a condition where "the product receives input that is expected to be of a certain type, but it does not validate or incorrectly validates that the input is actually of the expected type." The extended description notes that "attackers could trigger unexpected errors, cause incorrect actions to take place, or exploit latent vulnerabilities that would not be possible if the input conformed with the expected type."

CWE-1287 is a child of CWE-20 (Improper Input Validation) and a peer of CWE-843 (Type Confusion). It is classified as "Not Language-Specific (Often Prevalent)" and is typically introduced during implementation. Here, MongoDB Server's C++ codebase does not enforce type constraints on binary diff data before the oplog update path processes it.

BSONColumn involvement

The JIRA ticket SERVER-124959 is titled "Validate doc diff array bounds and $_internalApplyOplogUpdate BSON" with the description "Including BSONColumn fields." This indicates the vulnerability extends to BSONColumn-encoded data within document diffs. BSONColumn is a newer BSON serialization format, introduced in recent MongoDB versions to store columnar data more efficiently. That BSONColumn is in the fix scope suggests the type validation gap affects more than one serialization path in the document diff processing logic.

CVSS 4.0 breakdown

The CNA-assigned CVSS 4.0 vector is CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:N/VA:H/SC:N/SI:N/SA:N, scoring 7.2 (HIGH). The initial CVE record carries a CVSS score of 8.1. The key metrics break down as follows:

VC:H and VA:H together mean one bug hits both confidentiality and availability. The out-of-bounds read can expose sensitive data from the server's heap, which may include other users' data, internal server state, or credentials held in memory. The crash takes the database down completely.

Attack flow

From the vulnerability's characteristics, exploitation follows this sequence:

1. An attacker authenticates to the MongoDB server with any account that has access to the aggregate command. Most database users have this permission by default.
2. The attacker builds an aggregation pipeline that includes the $_internalApplyOplogUpdate stage.
3. Within this stage, the attacker supplies a document diff containing a carefully crafted malformed binary diff.
4. The malformed binary diff gets through because the oplog update processing code does not validate its type.
5. The server processes memory outside the intended buffer boundaries. It either returns out-of-bounds data to the attacker (information disclosure) or crashes (denial of service).

Because most users can run aggregate by default, the authentication requirement is a relatively low barrier. Any compromised application account, service credential, or insider with database access could carry out this attack.

Resolution timeline

Evan Bergeron created the JIRA ticket SERVER-124959 on April 21, 2026, and it was resolved on June 9, 2026, at 4:27 PM UTC. That is a 49-day window from internal discovery to public fix. The ticket was assigned to the Query Execution team and marked "Fully Compatible" for backwards compatibility, meaning the fix does not change existing application behavior.

Affected systems and versions

The JIRA ticket SERVER-124959 lists "Affects Version/s: None" in its metadata, so MongoDB did not formally enumerate affected versions. The fix versions, though, show the affected scope clearly. Patches were released across four release tracks:

Treat any MongoDB Server version below these releases on its track as vulnerable. The JIRA ticket documents no workaround. Upgrading to a fixed version is the only confirmed remediation.

Organizations running MongoDB Atlas managed clusters should check that each cluster runs a version at or above the fixed release for its track. Atlas clusters typically receive automatic updates.

Vendor security history

MongoDB has had a notable run of high-severity server vulnerabilities over the past year, and that history should inform how often organizations patch it.

MongoBleed let unauthenticated remote attackers read MongoDB's heap memory, exposing plaintext credentials. A working public PoC was published on GitHub on December 26, 2025, and Arctic Wolf reported that "threat actors began exploiting MongoBleed shortly after public disclosure." Bitsight confirmed it was "being actively exploited."

CVE-2026-25611, discovered by Cato CTRL researcher Vitaly Simonovich, was a pre-authentication memory exhaustion DoS that put over 210,000 MongoDB instances at risk. It required no authentication and could crash any reachable MongoDB server.

Memory safety vulnerabilities keep appearing in different server components (zlib decompression, wire protocol handling, aggregation pipeline stages, FLE query analysis), which points to a systemic input validation problem in MongoDB's C++ codebase. The CWE-1287 classification for CVE-2026-9753 fits that pattern, since the same class of weakness, improper type validation, has shown up across multiple code paths.

MongoDB acts as its own CVE Numbering Authority through [email protected] and maintains a structured security advisory process. It also releases patches across multiple supported tracks, which is good practice. Still, the frequency of these issues suggests organizations should patch MongoDB on a continuous cadence rather than treat each CVE as an isolated event.

References

• NVD: CVE-2026-9753
• MongoDB JIRA: SERVER-124959
• MongoDB Alerts
• Canadian Centre for Cyber Security: MongoDB Security Advisory AV26-468
• CWE-1287: Improper Validation of Specified Type of Input
• Bitsight: CVE-2025-14847 MongoDB MongoBleed
• Arctic Wolf: CVE-2025-14847 MongoBleed Information Disclosure
• Wiz: MongoBleed Exploited in the Wild
• Cato Networks: New MongoDB Vulnerability CVE-2026-25611
• NVD: CVE-2026-25611
• NVD: CVE-2026-8201
• NVD: CVE-2026-8053
• 6sense: MongoDB Market Share
• CISA Known Exploited Vulnerabilities Catalog