CVE-2026-92958 in vm2
Summary
by MITRE • 09/17/2026
vm2 through 3.11.6 contains a builtin-module denylist bypass in NodeVM. When the embedder uses the builtin wildcard together with negative entries (e.g. require: { builtin: ['*', '-fs', '-child_process'] }), negative entries are matched by exact module name in lib/builtin.js, so -fs removes only the builtin named fs and does not remove builtin subpaths such as fs/promises. Sandboxed code can therefore call require('fs/promises') or require('node:fs/promises') and reach the promise-based filesystem API despite fs being denied; node: prefix handling is likewise inconsistent (a -node:fs/promises entry does not block require('fs/promises')). Host file creation and writing were confirmed via fsp.writeFile(), and other fs/promises operations (cp, mkdir, rename, rm, rmdir, truncate, read operations, etc.) are also reachable. This issue is fixed in vm2 3.11.7.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 09/17/2026
The vulnerability identified in the NodeVM implementation within the vm2 library prior to version 3.11.6 represents a critical bypass of security controls designed to restrict access to sensitive Node.js built-in modules. This flaw specifically affects configurations where an embedder attempts to deny all builtin modules using a wildcard pattern while selectively allowing specific exceptions or denying sub-modules through negative entries. The core technical failure lies in the logic used within lib/builtin.js, which processes these configuration rules by matching module names exactly rather than evaluating hierarchical paths. Consequently, when a user specifies a denial for a parent module such as fs via an entry like -fs, the system only blocks direct access to that exact string and fails to extend this restriction to its subpaths or namespaces, such as fs/promises. This inconsistency creates a significant gap in the sandbox boundary, allowing untrusted code to bypass intended restrictions by accessing alternative API endpoints provided by the same underlying module family.
From an operational perspective, this flaw enables malicious actors executing within the restricted NodeVM environment to perform file system operations that were explicitly supposed to be prohibited. By invoking require('fs/promises') or requiring modules with the node: prefix such as node:fs/promises, attackers can access the promise-based filesystem API despite fs being listed in the denylist. This capability allows for host file creation and writing through methods like fsp.writeFile(), as well as other destructive or exfiltrative operations including copying files, creating directories, renaming, removing files or directories, truncating data, and reading sensitive information from the host system. The inconsistency extends to node: prefix handling as well; specifying a denial entry for -node:fs/promises does not effectively block access to fs/promises, further complicating secure configuration attempts and leaving multiple avenues open for exploitation against applications relying on vm2 for sandboxing untrusted JavaScript code.
This vulnerability aligns with CWE-749, which describes exposure of a dangerous method or function to an unauthorized actor, as it allows execution of privileged file system operations within a context that should be isolated from such capabilities. In the context of the MITRE ATT&CK framework, this flaw facilitates techniques associated with Collection and Exfiltration over Alternative Protocol, specifically allowing attackers to gather data from local systems through file read operations or potentially impact availability by modifying or deleting files via write and remove operations. The root cause is a failure in input validation logic regarding hierarchical module resolution within the sandboxing engine, leading to an incomplete implementation of access control policies defined by the application developer.
To mitigate this risk, organizations utilizing vm2 must immediately upgrade to version 3.11.7 or later, where the builtin-module denylist bypass has been resolved and subpath handling is corrected to ensure that denying a parent module effectively blocks all its associated namespaces and prefixes. Until an update can be applied, developers should avoid relying solely on wildcard denials with negative exceptions for critical security boundaries; instead, they should explicitly list every required allowed module in the whitelist while keeping the denylist minimal or empty if possible. Additionally, implementing defense-in-depth strategies such as running NodeVM instances within containers with restricted file system permissions can limit the impact of any successful exploitation by preventing write access to sensitive host directories regardless of the sandbox configuration errors.