Introduction
A use-after-free vulnerability in MongoDB Server's MozJS BSON binding layer lets any authenticated user with read privileges trigger memory disclosure or a server crash through server-side JavaScript operators that are deprecated but still widely available. The flaw is tracked as CVE-2026-11933 and has a CVSS v4.0 score of 8.7. It comes from an ownership semantics mismatch in how BSON documents are converted to JavaScript arrays, and it affects every supported MongoDB release line from 4.4 through 8.3.
CVE-2026-11933 is the latest in a cluster of use-after-free issues found in MongoDB's JavaScript engine integration layer. It joins CVE-2026-8336 and the much older CVE-2019-2390 in the same code path. Combined with the recent MongoBleed (CVE-2025-14847) exploitation campaign, it reinforces that memory management in MongoDB's scripting subsystems is still an active security concern.
Technical Information
Root Cause: Ownership Semantics Mismatch in bsonObjToArray
The vulnerability is in MongoDB's MozJS BSON binding layer, the code that marshals BSON data structures into SpiderMonkey (MozJS) JavaScript objects during server-side script execution. According to MongoDB JIRA ticket SERVER-128125, titled "Align bsonObjToArray ownership semantics with bsonGetImmutable," the root cause is an inconsistency between two related functions:
bsonGetImmutablecorrectly ensures that the underlyingBSONObjis owned, meaning the memory backing the BSON document is guaranteed to stay valid, before it creates JavaScript wrappers that reference it.bsonObjToArraydoes not apply the same ownership check when it operates on sub-document wrappers.
So when bsonObjToArray processes BSON documents that contain arrays during server-side JavaScript execution, the resulting JavaScript array objects may hold pointers into memory the BSON layer has already freed. Any later read or write through those dangling references is a use-after-free.
The CWE assignment, CWE-787 (Out-of-bounds Write), reflects the downstream consequence. Accessing freed memory amounts to an out-of-bounds memory operation, because the freed region may have been reallocated for a different purpose.
CVSS v4.0 Vector Analysis
MongoDB, acting as CNA, assigned this CVSS v4.0 vector:
CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N
| Metric | Value | Significance |
|---|---|---|
| Attack Vector (AV) | Network | Exploitable remotely over the network |
| Attack Complexity (AC) | Low | No special conditions required |
| Attacker Requirements (AT) | None | No prior access beyond authentication needed |
| Privileges Required (PR) | Low | Only authenticated read access needed |
| User Interaction (UI) | None | No user action required |
| Vulnerable System Confidentiality (VC) | High | Full process memory may be disclosed |
| Vulnerable System Integrity (VI) | High | Potential for memory corruption |
| Vulnerable System Availability (VA) | High | Server crash causes full denial of service |
The NVD has not yet done its own independent CVSS assessment. The 8.7 score comes from MongoDB, Inc. as the CNA.
Attack Flow
Exploitation proceeds in four steps:
-
The attacker authenticates to a MongoDB instance with at least read privileges on a target collection. That is the minimum privilege level, and no administrative or cluster-level roles are required.
-
The attacker builds a query or aggregation pipeline that uses the
$whereoperator or the$functionaggregation operator.$whereevaluates a JavaScript expression or function against each document to decide whether it matches the filter.$functiondefines custom aggregation expressions that run on the database server. -
When the query engine processes documents that contain BSON arrays, it calls
bsonObjToArrayto convert those arrays into JavaScript array objects for the JavaScript execution context. Because the ownership check is missing, the JavaScript engine receives references to memory that the BSON layer may later free. -
Later access to these stale references makes the
mongodprocess read from or write to freed memory. Depending on the state of the heap, this can result in:- Information disclosure: The freed region may have been reallocated and filled with other data from the
mongodprocess, which can include sensitive information such as credentials, encryption keys, or other users' document data. - Denial of service: If the freed memory is in an inconsistent state, the access triggers a segmentation fault or assertion failure, and the
mongodprocess crashes.
- Information disclosure: The freed region may have been reallocated and filled with other data from the
Deprecated Operators as the Attack Surface
The $where, $function, and $accumulator operators are formally deprecated as of MongoDB 8.0. They have not been removed, though. They still work in current releases and are still widely used in legacy applications. Deprecation does shrink the long-term attack surface for organizations that migrate to native aggregation pipeline operators such as $match, $expr, and $lookup.
Interim Workaround: Disabling Server-Side JavaScript
Organizations that cannot upgrade immediately can use a MongoDB configuration option to disable server-side JavaScript execution entirely:
security: javascriptEnabled: false
This setting disables all server-side JavaScript, including $where, $function, $accumulator, and mapReduce operations. That shuts off the attack vector, but it will also break any application functionality that depends on these operators.
Defense in Depth Recommendations
- Review role-based access control (RBAC) to confirm that application accounts do not have unnecessary privileges to execute server-side JavaScript operators.
- Refactor queries to use native aggregation pipeline operators instead of JavaScript-based expressions.
- Limit network access to MongoDB instances to trusted application servers only.
- Enable MongoDB audit logging and monitor for unexpected use of
$whereor$functionoperators, particularly from low-privilege accounts. - MongoDB Atlas may disable server-side JavaScript by default for certain configurations. Organizations running Atlas should check their cluster's
security.javascriptEnabledsetting and confirm their cluster version meets or exceeds the fixed versions.
Affected Systems and Versions
The JIRA ticket lists 8.0.27 as the affected version and gives these fixed versions across all supported release lines:
| Release Line | Fixed Version |
|---|---|
| 4.4 | 4.4.31 |
| 5.0 | 5.0.34 |
| 6.0 | 6.0.29 |
| 7.0 | 7.0.37 |
| 8.0 | 8.0.26 |
| 8.2 | 8.2.11 |
| 8.3 | 8.3.4 |
Any MongoDB Server version below the fixed version for its release line is vulnerable if server-side JavaScript execution is enabled, which it is by default.
The fix is marked "Fully Compatible" for backwards compatibility, so upgrades within the same release line should not introduce breaking changes.
Vendor Security History
CVE-2026-11933 fits a recurring pattern of memory-safety issues in MongoDB's scripting and query layers.
CVE-2019-2390 affected MongoDB Server v3.4 prior to 3.4.22, v3.6 prior to 3.6.14, and v4.0 prior to 4.0.11. It let an authenticated user trigger a use-after-free that could crash MongoDB Server. Use-after-free conditions have recurred in the BSON-to-JavaScript conversion layer over several years, which suggests this code path has been a persistent memory-safety problem.
Between May 2026 and the publication of CVE-2026-11933, MongoDB disclosed several more vulnerabilities:
| CVE ID | Subsystem | CVSS | Description |
|---|---|---|---|
| CVE-2026-4148 | Aggregation ($lookup/$graphLookup) | 8.7 | ExpressionContext UAF on sharded clusters |
| CVE-2026-8336 | Server-side JS ($_internalJsEmit/mapReduce) | 7.7 | Post-auth UAF in JS execution |
| CVE-2026-8201 | Field-Level Encryption | 6.1 | UAF in FLE query analysis |
| CVE-2026-25611 | JSON parsing | N/A | Denial of service via date value handling |
| CVE-2025-14847 | Zlib compression | Critical | MongoBleed: unauthenticated memory disclosure |
| CVE-2025-6713 | Aggregation ($mergeCursors) | Critical | Unauthorized data access bypassing RBAC |
The use-after-free vulnerabilities cluster in the server-side JavaScript and aggregation subsystems. That suggests the MozJS integration layer and the query execution engine carry elevated memory-safety risk within the MongoDB codebase.
Independent security analysts describe MongoDB as having a "solid track record of addressing vulnerabilities promptly" with a "mature security response process." For CVE-2026-11933, the fix went from internal tracking to deployment across seven release branches in 9 days, which is consistent with that description.
A larger question is whether embedding a JavaScript engine (SpiderMonkey/MozJS) in the database server creates an inherent, persistent memory-safety attack surface that individual patches cannot fully address. MongoDB's deprecation of server-side JavaScript operators in MongoDB 8.0 may be its own acknowledgment of this architectural concern.
References
- NVD: CVE-2026-11933
- MongoDB JIRA: SERVER-128125
- MongoDB Server-side JavaScript Documentation
- MongoDB Alerts
- CWE-787: Out-of-bounds Write
- CISA Known Exploited Vulnerabilities Catalog
- MongoBleed (CVE-2025-14847) Exploited in the Wild: Wiz
- Threat Brief: MongoDB Vulnerability (CVE-2025-14847): Palo Alto Unit 42
- MongoDB CVE-2025-6713: Unauthorized Data Access: ZeroPath
- CVE-2026-8201: NVD
- CVE-2026-25611: MongoDB Server DOS Vulnerability: SentinelOne
- CVE-2019-2390: NVD
- MongoDB $where Operator JavaScript Injection: Invicti
- MongoBleed Vulnerability: CVE-2025-14847: Phoenix Security
- Important MongoDB Patch Available: May 2026
- CVEs, Same Playbook: 2026 Vulnerability Exploitation in the Wild: Proofpoint



