vm2 vulnerabilities

vm2 through 3.12.0 exposes Node.js's crypto.setFips() function to untrusted guest code when an embedder explicitly allowlists the crypto builtin for a NodeVM. The sanitizer leaves crypto.setFips callable, allowing guest code to change the FIPS mode of the entire host process, crossing the NodeVM isolation boundary. Fixed in vm2 3.12.1.

vm2, a sandbox for running untrusted JavaScript, in versions up to and including 3.11.3 uses prototype-walking index assignment in defaultSandboxPrepareStackTrace, allowing sandbox code to intercept error stack lines. The impact is low (information side channel) and the issue is fixed in version 3.11.4.

vm2 versions 3.11.4 through 3.11.6 incompletely filter Node.js registered internal symbols across the sandbox boundary. The extraction filters in lib/setup-sandbox.js and the cross-realm symbol checks and write traps in lib/bridge.js use a fixed list of known dangerous registered symbols that omits nodejs.stream.disturbed and nodejs.stream.errored, which are exposed on host WebStream prototypes on newer Node.js releases. When the embedder exposes a host WebStream object and the host stream/web module to the sandbox, sandbox code can obtain the real host symbols and use them as write keys on host stream objects, corrupting host-visible stream state. This can bypass host logic that relies on Node's public stream-state helpers. It is not a host code-execution primitive in the reported proof of vulnerability. This is an incomplete fix for the earlier nodejs.* symbol filtering issue. Fixed in vm2 3.11.7.

A vulnerability in the vm2 CLI tool (before 3.11.7) allows sandbox escape and arbitrary code execution in the host Node.js process. Attackers can supply a malicious script that uses require(__filename) to re-execute itself in the host realm, bypassing sandbox isolation and accessing host modules like fs and child_process.

vm2 before 3.11.7 contains a module allowlist bypass vulnerability in isPathAllowedForModule that uses raw string prefix matching instead of boundary-anchored comparison. Attackers can reach non-allowlisted packages sharing a prefix with allowlisted modules by performing relative requires from allowlisted packages when transitive loading is disabled.

vm2 versions 3.11.0 through 3.11.6 leak absolute host filesystem paths to sandboxed code through error stack formatting. Attacker-supplied code can force the host-realm source transformer to throw a SyntaxError and then read the error's .stack property, bypassing the sandbox-side host-path redaction. Default new VM() and new NodeVM() configurations are affected without any special options.

A vulnerability in vm2 before 3.12.2 allows an authorization bypass in the NodeVM external-module resolver. When an embedder configures `require.external` with a custom resolver and `context: 'host'`, guest code can require an allowlisted module and then an absolute path of a non-allowlisted sibling sharing the resolved prefix. This leads to a sandbox escape and arbitrary code execution in the host process.

A vulnerability in the vm2 library (npm) versions up to 3.12.0 allows sandbox escape in VM and NodeVM. When an embedder exposes a host API returning a host-realm Promise, the rejection sanitizer does not cover all cases, and sandboxed code can overwrite Promise properties to obtain an unsanitized host object. This can lead to arbitrary code execution on the host. Fixed in 3.12.1.

A vulnerability in NodeVM of vm2 before 3.12.1 allows sandbox escape because 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 when NodeVM is configured with builtin:['*'] or explicit child_process allowance.

A vulnerability in vm2 through 3.12.0 (fixed in 3.12.1) involves incorrect handling of a nullish `this` receiver in the apply trap of its bridge. When sandboxed code calls a host-provided non-strict function without a receiver, the undefined receiver is passed through, and V8 substitutes the host realm's global object. vm2 returns that object to the sandbox, allowing a complete sandbox escape and access to process. Exploitation requires the embedding application to expose at least one non-strict host function.

In vm2 before 3.11.6, the builtin: ['*'] configuration does not restrict access to os and dns builtins, allowing sandbox code to read host process identity and network topology. Attackers can use dns.setServers() to hijack the host process's DNS resolver globally.

vm2 through 3.11.6 does not normalize 'node:'-prefixed builtin specifiers when matching negative (deny) entries in a NodeVM wildcard require policy. A policy such as ['*', '-node:child_process'] fails to deny the canonical child_process module because matching uses exact string comparison against canonical builtin names. Sandboxed code can therefore obtain the host child_process builtin and gain access to process-spawning APIs such as execSync and spawn, equivalent to host command execution.

In vm2 versions 3.10.1 through 3.11.6, there is a sandbox escape via WebAssembly.compileStreaming and instantiateStreaming, allowing attackers to access the host process object on Node.js 26, leading to full host control.

In vm2 before 3.11.8, there is a sandbox escape vulnerability via console._stdout and console._stderr. Attackers can overwrite EventEmitter.prototype.emit and execute code on the host process, bypassing code generation restrictions.

In vm2 versions from 3.11.0 before 3.11.8, host TypedArray and ArrayBuffer prototypes are not protected from sandbox mutation. Attackers can modify prototypes, affecting host-created typed arrays and potentially leading to unauthorized actions.

vm2 before 3.11.7 contains an incorrect authorization vulnerability in the external package allowlist check that uses non-exact substring matching instead of full package-name boundary validation. Attackers can bypass the allowlist by requiring a colliding package name that contains an allowlisted package substring, causing vm2 to load and execute unauthorized host packages in the host context.

vm2 versions >= 3.9.6 and <= 3.11.6 are affected by a NodeVM builtin allowlist bypass that permits a sandbox escape on Node.js 24 and newer when the embedder explicitly allows the node:test builtin. On Node.js 24+, module.builtinModules exposes the scheme-only key node:test, which is not covered by vm2's family-based DANGEROUS_BUILTINS protection, and because requireImpl() strips only a single 'node:' prefix, sandbox code calling require('node:node:test') receives a proxy to the host module, with node:test.run() forwarding attacker-controlled execArgv (e.g. --eval) to execute arbitrary JavaScript in an unrestricted host process.

vm2 before 3.11.7 exposes Node's shared Buffer pool to sandboxed code, allowing disclosure of host memory used by Buffer.from, Buffer.concat, and related allocations. Sandboxed code can read and write to host-realm buffers by acquiring ArrayBuffers from small allocations, leading to sensitive data exposure and potential denial-of-service.

vm2 before 3.11.7 contains a remote code execution vulnerability when require.external is enabled without an explicit require.root that excludes node_modules. Sandboxed code can require vm2's own package, instantiate an unrestricted NodeVM instance, and execute arbitrary host OS commands via child_process.

vm2 versions 3.10.2 through 3.11.6 contain a sandbox escape vulnerability on Node.js 26 where Promise.prototype.finally() bypasses vm2's wrapper protections due to a stale PromiseThenLookupChain protector in V8 14.6. Attackers can exploit this by creating an async function that returns a Promise with an attacker-controlled constructor Symbol.species, allowing them to reach the host Function constructor and process object for arbitrary code execution.

vm2 versions from 3.11.3 before 3.11.7 expose the host tls module to NodeVM sandbox code, allowing attackers to call tls.setDefaultCACertificates() and replace process-wide certificate authorities. Attackers with access to allowed tls and url builtins can use URLSearchParams to create host-realm arrays and manipulate the TLS trust store, enabling subsequent host HTTPS clients to accept attacker-controlled certificates.

vm2 versions 3.11.3 through 3.11.6 expose the host process's real https.globalAgent to sandboxed code when a NodeVM is explicitly configured to allow require('https'). Although host modules are wrapped in a read-only proxy, method calls such as Agent.prototype.on() are forwarded to the underlying host object, so sandbox code can register a listener for the agent's 'free' event. When an unrelated host HTTPS request releases a pooled connection, the listener receives the live host request options and the host TLSSocket, allowing sandboxed code to read the host's Authorization header and private destination host/port, read subsequent host response bodies in plaintext, and issue attacker-chosen authenticated requests using the stolen credentials.

vm2 3.11.3 through 3.11.6 exposes the host Node.js crypto module to a NodeVM sandbox when the crypto builtin is allowed. The module is presented via a recursive read-only proxy, but its callable exports still execute with host-process authority, so sandboxed JavaScript can call crypto.setEngine() with a filesystem path to an attacker-supplied native library; OpenSSL asks the operating-system dynamic loader to load the file, and the library's constructor executes native code in the host process before engine-symbol validation rejects it. Exploitation requires only the crypto builtin and results in a sandbox escape and arbitrary native code execution.

vm2 versions 3.11.3 through 3.11.6 expose Node.js's host node:sqlite module to code running in NodeVM when that builtin is permitted, either explicitly or through builtin: ['*']. The module is wrapped with vm.readonly(), which prevents property assignment but leaves host-authority callables reachable; in addition, the resolver treats any request starting with 'node:' as a core-module request and the runtime strips only one 'node:' prefix, so a sandbox request for 'node:node:sqlite' resolves to the configured node:sqlite entry. Sandboxed code can therefore create an in-memory DatabaseSync with extension loading enabled and call DatabaseSync.loadExtension() on a native library bundled in the untrusted plugin package, giving the sandboxed plugin arbitrary native code execution outside the sandbox with the host process's privileges.

vm2 3.11.6 is vulnerable to a sandbox escape leading to remote code execution in the host Node.js process. The fix for GHSA-m283-3h24-438v is incomplete: the bridge gate at lib/bridge.js:1624 identity-checks only the direct call target when deciding whether to rebuild/sanitise a rejected host Promise value. Registering the rejection handler through Function.prototype.call or .apply indirection (e.g., p.then.call(p, undefined, cb)) makes the intercepted target host Function.prototype.call, so the sanitiser never runs and the raw host error reaches sandbox code with its own properties intact. If an embedder exposes a host-realm Promise to the sandbox and that Promise rejects with an Error carrying a non-primitive own property referencing a host object (for example err.detail = process), untrusted code in the sandbox obtains a fully functional proxy to that host object and can execute arbitrary commands with the privileges of the host process.

vm2, a sandbox for running untrusted Node.js code, in versions 3.11.4–3.11.6 incorrectly treats an array passed as the 'require' option (e.g. require: []) as a valid configuration, bypassing the guard meant to reject nesting without an explicit require configuration. An attacker can then 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. This is fixed in vm2 3.11.7.

vm2 before 3.11.8 contains an incomplete fix for Error.cause sanitization that allows sandbox escape when revisited host-wrapped AggregateError objects are caught within a single exception handler traversal. Attackers can exploit a cycle detection bypass in handleException to access unsanitized host proxies embedded in the errors array, enabling full remote code execution and process information disclosure from the sandbox.

vm2 is an open source vm/sandbox for Node.js. Prior to 3.11.6, lib/bridge.js and lib/setup-sandbox.js fail to block stacked indirection through Function.prototype.call around dangerous host prototype getter and setter mutators, allowing sandbox code to sever a host intrinsic's prototype chain and reach e.constructor.constructor for arbitrary host command execution. This issue is fixed in version 3.11.6.

vm2 is an open source vm/sandbox for Node.js. Prior to 3.11.6, handleException() in lib/setup-sandbox.js sanitizes SuppressedError.error, SuppressedError.suppressed, and AggregateError.errors but does not sanitize Error.cause, allowing sandbox code to obtain a powerful host object such as process from an embedder-exposed host function that throws an error with that object as its cause and then execute arbitrary host commands. This issue is fixed in version 3.11.6.

In vm2, prior to version 3.11.4, a sandbox escape vulnerability allowed arbitrary code execution in the host process when untrusted code was executed with async support. This issue has been patched in version 3.11.4.

vm2 is an open source vm/sandbox for Node.js. Prior to version 3.11.4, vm2 suffers from a sandbox breakout vulnerability, allowing attackers to execute arbitrary commands on the host system.

vm2 is an open source vm/sandbox for Node.js. Prior to version 3.11.4, NodeVM blocks several dangerous Node.js builtins, but the denylist misses process and inspector/promises, allowing sandboxed code to bypass restrictions.

In versions prior to 3.11.4, the vm2 library contained a vulnerability that allowed bypassing security related to the 'nesting: true' and 'require: false' options. The strict equality check in the code did not function correctly, enabling unauthorized requirements.

vm2 is an open source vm/sandbox for Node.js. Prior to version 3.11.4, by combining certain calls, it was possible to obtain the host's TypeError constructor, allowing escape from the sandbox and execution of arbitrary code.

In the vm2 library for Node.js prior to version 3.11.3, a vulnerability allows catching a host exception using the yield* expression inside an async generator. Closing the generator with the return function causes the value to be awaited, and exceptions thrown in the then call can be caught and passed as the next value to the yield* iterator, enabling sandbox escape and arbitrary command execution on the host system.

A vulnerability in the vm2 library for Node.js allows sandbox escape. The issue is fixed in version 3.11.2.

A vulnerability in the vm2 library for Node.js prior to version 3.11.2 allows sandbox escape via the neutralizeArraySpeciesBatch method, which can call into the host side using a getter on the array prototype. This enables attackers to obtain host objects and the Function object, leading to arbitrary command execution on the host system.

A vulnerability in the vm2 library for Node.js allows bypassing the require configuration in NodeVM with nesting enabled. Sandbox code can require the vm2 module, create a new NodeVM instance with unrestricted require, and execute arbitrary OS commands on the host.

A vulnerability in the vm2 library for Node.js allows an attacker to bypass sandboxing and access arbitrary object prototypes. The issue is fixed in version 3.11.0.

A vulnerability in the vm2 library for Node.js (versions 3.9.6 to 3.10.5) allows attacker-controlled JavaScript running in the sandbox to mutate host prototypes such as Object.prototype, Array.prototype, and Function.prototype. This occurs because the bridge exposes mutable proxies for real host-realm intrinsic prototypes and forwards sandbox writes to host objects using ReflectSet() and ReflectDefineProperty().

A vulnerability in vm2 prior to 3.11.0 allows bypassing the NodeVM builtin allowlist. When the 'builtin' module is allowed (even via '*' wildcard), sandboxed code can use Module._load() to load any module in the host context, bypassing restrictions. This enables loading excluded modules like child_process and achieving remote code execution.

A vulnerability in the vm2 library for Node.js prior to version 3.11.0 allows obtaining the host object. Attackers can use various methods, e.g., HostObject.getOwnPropertySymbols, to obtain Symbol(nodejs.util.inspect.custom) and escape the sandbox.

A vulnerability in the vm2 library for Node.js version 3.10.4 allows full sandbox escape with arbitrary code execution. An attacker can obtain the host process object and run host commands without any host cooperation.

A vulnerability in the vm2 library for Node.js allows attackers to escape the sandbox and execute arbitrary code via the SuppressedError mechanism. The issue is fixed in version 3.11.0.

A vulnerability in the vm2 library for Node.js allows sandbox escape via the inspect function. Attackers can execute arbitrary commands on the host system.

A vulnerability in the vm2 library for Node.js allows bypassing the fix for CVE-2023-37466 and escaping the VM2 sandbox, enabling arbitrary command execution on the host. The issue is patched in version 3.10.5.

VM2 is an open source VM/sandbox for Node.js. Prior to version 3.11.0, it suffers from a sandbox breakout vulnerability allowing attackers to execute arbitrary commands on the host system.

vm2 is an open source vm/sandbox for Node.js. In versions up to and including 3.9.19, the inspect function in Node.js allows attackers to escape the sandbox and run arbitrary code.

The vm2 library, an advanced sandbox for Node.js, contains critical security issues and should not be used in production. In versions up to 3.9.19, `Promise` handler sanitization can be bypassed, allowing attackers to escape the sandbox and execute arbitrary code.

vm2 before 3.12.2 does not apply its Buffer backing-store ownership invariant (byteOffset === 0 and buffer.byteLength === length) to Buffers returned from host builtin modules. When an application exposes Node's zlib module through NodeVM's builtin allowlist, zlib.deflateSync can return a Buffer backed by Node's shared small-buffer pool whose .buffer is the entire pool. Untrusted guest code can construct a full-width view of that ArrayBuffer to read and modify bytes belonging to unrelated host buffers.