CVE-2026-92957 in vm2
Summary
by MITRE • 09/17/2026
vm2 through 3.11.6 does not normalize `node:`-prefixed builtin specifiers when evaluating user-supplied negative (deny) entries in a NodeVM wildcard require policy. Although NodeVM strips the `node:` prefix during require() resolution, negative wildcard entries are matched by exact string comparison against the canonical builtin names, so a policy such as `new NodeVM({ require: { builtin: ['*', '-node:child_process'] } })` fails to deny the canonical `child_process` module. Sandboxed code can therefore obtain the host `child_process` builtin via `require('child_process')` or `require('node:child_process')`, gaining references to process-spawning APIs such as execSync and spawn, which is equivalent to host command-execution capability for untrusted sandbox code. Fixed in vm2 3.11.7. (Suggested title: "vm2 before 3.11.7: NodeVM builtin deny-list bypass via node:-prefixed specifiers exposes child_process")
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 09/17/2026
The vulnerability identified in the vm2 library, specifically affecting versions prior to 3.11.7, represents a critical security flaw within its sandboxing mechanism for Node.js environments. This issue stems from an inconsistency in how the library handles module specifier normalization when evaluating deny-list entries against wildcard allow policies. The core of the problem lies in the disparity between how positive and negative rules are processed during the require resolution phase. When a user-supplied policy includes a wildcard to allow all built-in modules, such as using the asterisk character, vm2 is designed to permit access unless explicitly denied by subsequent entries. However, the logic used to match these denial entries against resolved module names fails to account for modern Node.js specifier conventions that utilize the node: prefix.
In standard Node.js operation, both require('child_process') and require('node:child_process') resolve to the same canonical internal module name, which is simply child_process. The vm2 library correctly strips the node: prefix when resolving positive allow-list entries, ensuring that sandboxed code can access built-ins as expected under normal circumstances. However, this normalization step was omitted for negative deny-list entries. Consequently, if a security policy attempts to block specific dangerous modules by listing them with the node: prefix, such as specifying -node:child_process in the builtin array, the system performs an exact string comparison against the canonical name child_process. Since the strings node:child_process and child_process are not identical, the match fails, and the deny rule is effectively ignored.
This technical flaw allows untrusted code running within a NodeVM sandbox to bypass intended restrictions on sensitive built-in modules. Specifically, attackers can exploit this discrepancy by requesting the child_process module using either require('node:child_process') or potentially leveraging other variations that trigger the same resolution path without triggering the faulty deny check. Once access is granted, the attacker gains references to powerful APIs such as execSync and spawn. These functions enable arbitrary command execution on the host system where the Node.js process is running. This capability effectively breaks out of the sandbox environment, granting the malicious code full control over the underlying operating system shell, which constitutes a severe remote code execution risk in contexts where vm2 is used to isolate untrusted scripts from the main application logic.
From an industry standards perspective, this vulnerability aligns with CWE-749: Exposure of Dangerous Method or Function to Uncontrolled Code. The sandboxing mechanism intended to restrict access to dangerous methods fails due to a logical error in input validation and rule matching. Furthermore, within the MITRE ATT&CK framework for Enterprise, this behavior facilitates Command and Control techniques, specifically those involving system command execution via built-in utilities like cmd.exe or /bin/sh through Node.js APIs. The failure to properly sanitize and normalize inputs before applying security policies is a classic example of how improper neutralization can lead to privilege escalation within application-level sandboxes.
The operational impact of this vulnerability is severe for any organization relying on vm2 to execute untrusted JavaScript code, such as in online coding platforms, plugin systems, or serverless function environments. An attacker who gains access to the sandboxed environment can not only read sensitive data but also modify files, install malware, pivot to other internal network resources, and exfiltrate credentials stored within the host process memory. The lack of proper normalization means that security policies configured by developers are rendered ineffective if they rely on node-prefixed specifiers for deny rules, creating a false sense of security while leaving critical attack vectors open.
Mitigation strategies primarily involve upgrading to vm2 version 3.11.7 or later, where this normalization logic has been corrected to ensure that both allow and deny lists are evaluated against the canonical module names regardless of whether they include the node: prefix. For environments unable to upgrade immediately, developers should avoid using the node: prefix in their deny-list configurations if possible, relying instead on standard bare-module names like child_process for negative entries. Additionally, implementing stricter sandboxing policies that limit access to built-in modules entirely, rather than attempting fine-grained allow and deny lists, can reduce the attack surface. Monitoring logs for attempts to load suspicious modules or unusual process spawning activities within Node.js applications is also recommended as a defensive measure while patching efforts are underway.