CVE-2026-93605 in vm2
Summary
by MITRE • 09/18/2026
vm2 NodeVM versions before 3.12.1 contain a sandbox escape vulnerability where the DANGEROUS_BUILTINS denylist omits child_process despite blocking other host-spawning modules. Attackers can require child_process and execute arbitrary commands on the host system when NodeVM is configured with builtin:['*'] or explicit child_process allowance.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 09/18/2026
The vm2 library, a widely used JavaScript sandboxing solution for Node.js environments, suffered from a critical security flaw in versions prior to 3.12.1 that allowed attackers to escape the isolated execution context and gain control over the host system. This vulnerability stems from an incomplete implementation of the denylist mechanism designed to restrict access to dangerous built-in modules within the sandboxed environment. Specifically, while the library correctly blocked several high-risk modules capable of spawning external processes or accessing sensitive file systems, it failed to include child_process in this exclusion list despite its well-documented potential for arbitrary command execution. This oversight created a significant gap in the security boundary that vm2 is intended to enforce, allowing code running inside the sandbox to bypass isolation restrictions when specific configuration options were enabled.
The technical root cause of this vulnerability lies in how NodeVM handles module resolution and built-in access controls. When developers configure NodeVM with builtin set to an asterisk or explicitly allow child_process, they intend to provide necessary functionality while maintaining security through other means such as filesystem restrictions or network limitations. However, because the DANGEROUS_BUILTINS array did not include child_process, any code executed within the sandbox could directly require and instantiate this module. Once instantiated, the attacker gains access to methods like exec, spawn, and fork, which allow for the execution of arbitrary operating system commands with the same privileges as the Node.js process hosting the vm2 instance. This effectively nullifies the purpose of using a sandbox in scenarios where untrusted code is being evaluated or executed.
From an operational perspective, this vulnerability poses severe risks to applications that rely on vm2 for processing user-supplied JavaScript, such as online coding platforms, template engines, or automated testing frameworks. An attacker who can inject malicious scripts into these systems could achieve remote code execution on the underlying server. This leads to a complete compromise of the host environment, potentially resulting in data exfiltration, lateral movement within internal networks, installation of persistent backdoors, or denial of service through resource exhaustion. The impact is particularly acute because many developers assume that enabling sandboxing provides sufficient protection against untrusted code without realizing that misconfiguration can lead to total isolation failure.
This flaw aligns with CWE-250, which describes execution with unnecessary privileges, and CWE-693, Protection Mechanism Failure, as the security control failed to prevent access to a dangerous resource due to an incomplete implementation of protective measures. In terms of the MITRE ATT&CK framework, this vulnerability facilitates techniques associated with Command and Scripting Interpreter abuse, specifically allowing attackers to execute commands via system utilities like sh or cmd through Node.js wrappers. It also relates to Defense Evasion by bypassing sandbox restrictions that are supposed to contain malicious activity within a limited context.
To mitigate this risk, organizations using vm2 must immediately upgrade to version 3.12.1 or later where the child_process module has been correctly added to the denylist of dangerous built-ins. For environments running older versions that cannot be updated instantly, it is critical to ensure that NodeVM is never configured with builtin set to an asterisk unless absolutely necessary and even then only if strict additional controls are in place. Developers should avoid explicitly allowing child_process within sandbox configurations and instead rely on the default secure settings which restrict access to host-spawning modules by default. Regular security audits of JavaScript dependencies and their configuration parameters are essential to prevent similar oversights where critical built-in modules remain accessible due to incomplete denylists or allowlist logic errors.