Description

vm2 is a sandbox for running untrusted Node.js code. In versions >= 3.11.4 and <= 3.11.6, the NodeVM constructor computes `hasRealRequireConfig` with `typeof requireOpts === 'object' && requireOpts !== null`, so an array-shaped `require` value (for example `require: []`) satisfies the guard that is meant to reject nesting without an explicit require configuration. `makeResolverFromLegacyOptions()` then destructures the array into undefined option fields and returns a resolver containing only `NESTING_OVERRIDE.vm2`. As a result, an attacker who can supply JavaScript executed by a NodeVM configured with truthy `nesting` and an array-shaped `require` (e.g. `new NodeVM({nesting: true, require: []})`) can require the host `vm2` module, create an inner NodeVM with an attacker-chosen builtin allowlist (such as `child_process`), and execute arbitrary commands with the privileges of the host Node.js process, escaping the sandbox. Outer builtin restrictions do not constrain the attacker-created inner NodeVM. This issue is fixed in vm2 3.11.7.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "9.0",
  "pubDate": "2026-09-17T14:17:57.810Z",
  "pubdate": "2026-09-17T14:17:57.810Z",
  "executiveSummary": "The vm2 Node.js sandbox library is vulnerable to a sandbox escape, allowing attackers to execute arbitrary code with the privileges of the host Node.js process.\nThe vulnerability type is a security restriction bypass, specifically stemming from improper validation of the 'require' configuration object within the NodeVM constructor.\nAffected versions include vm2 from 3.11.4 through 3.11.6.\nBy providing an array-shaped 'require' configuration alongside an enabled 'nesting' option, an attacker can bypass intended restrictions on nesting NodeVM instances.\nThis allows the attacker to initialize an inner NodeVM with an arbitrary, elevated allowlist of builtin modules—such as 'child_process'—that are typically restricted or prohibited.\nThe primary risk implication is a total compromise of the host environment, as the attacker can perform unrestricted system operations.\nExploitation requires an attacker to have the ability to supply JavaScript code that is executed within the context of a NodeVM instance configured with the specified parameters.",
  "technicalDetails": "The vulnerability resides within the NodeVM constructor's logic for computing the 'hasRealRequireConfig' variable. Specifically, the check 'typeof requireOpts === 'object' && requireOpts !== null' is insufficient because it treats array-type inputs (e.g., 'require: []') as valid objects.\nWhen a user initializes 'new NodeVM({nesting: true, require: []})', the 'hasRealRequireConfig' guard erroneously identifies the configuration as valid, bypassing the logic intended to block unauthorized nesting.\nThe 'makeResolverFromLegacyOptions()' function subsequently processes this array. Because the input is an array, the function destructures it into undefined fields, ultimately returning a resolver object that contains only the 'NESTING_OVERRIDE.vm2' property.\nThis override permits the attacker to require the host 'vm2' module from within the sandboxed environment, breaking the isolation barrier.\nOnce the host 'vm2' module is accessible, the attacker can instantiate a new, nested NodeVM instance from within the original sandbox. Crucially, this new inner NodeVM is not constrained by the security policies or builtin restrictions enforced by the outer, compromised sandbox.\nThe attacker can configure this nested NodeVM to allow access to sensitive host-level builtins, such as 'child_process', 'fs', or 'os'.\nThe attack flow follows these steps: 1) The attacker injects JavaScript code into a vulnerable NodeVM instance. 2) The attacker leverages the 'require: []' configuration bug to bypass nesting constraints. 3) The attacker requires the 'vm2' library to gain access to the host Node.js environment. 4) The attacker initializes a nested NodeVM instance with an unrestricted allowlist. 5) The attacker executes arbitrary system commands via the nested sandbox, effectively achieving host OS code execution.\nThis exploit successfully circumvents the security boundary intended to isolate untrusted user-supplied JavaScript, leading to complete sandbox breakout and privilege escalation to the level of the parent process."
}