vm2 vulnerabilities

vm2 before 3.12.2 does not apply host-side Promise rejection handling in the sandbox-to-host construct trap. In BaseHandler, the apply trap calls markHostPromiseHandled() on the returned value, but the adjacent construct path returns the result of Reflect.construct without the same sanitization. If an embedder exposes a constructable host function whose constructor returns a native rejected Promise, an untrusted script executed via VM.run can invoke it with `new` and ignore the result; the rejected host Promise crosses the bridge unhandled and, under Node's strict unhandled-rejection policy, is promoted to an uncaught exception that terminates the host process.

vm2 versions before 3.11.2 fail to properly restrict access to the VM2_INTERNAL_STATE_DO_NOT_USE_OR_PROGRAM_WILL_FAIL global variable. Attackers can access this internal state object through globalThis to retrieve sensitive sandbox internals.

vm2 before 3.11.6 fails to enforce bufferAllocLimit on ArrayBuffer, SharedArrayBuffer, and TypedArray constructors, allowing attackers to allocate arbitrary host memory. Attackers can bypass the buffer allocation cap by using these V8 intrinsics to exhaust host process memory and trigger out-of-memory conditions.

vm2 before 3.11.8 does not fully enforce the allowAsync: false option in VM and NodeVM. While localPromise.prototype.then is replaced with a handler that throws 'Async not available', the sandbox's Promise static methods (Promise.resolve, Promise.all, Promise.race, Promise.any, and Promise.allSettled) still assimilate attacker-supplied thenables, allowing sandboxed script to schedule work that runs after VM.run() or NodeVM.run() has returned and outside the configured timeout.

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, 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.

vm2 versions >= 3.10.0 and <= 3.11.7 do not mark Promises returned from the host realm into the sandbox as handled at the bridge boundary. Only Promises created inside the sandbox are wrapped with a rejection-swallowing handler, and the bridge only installs host-side rejection sanitizers when sandbox code calls .then/.catch/.finally. As a result, sandboxed code can invoke a host function that returns a rejected Promise and ignore the return value, leaving the host Promise unhandled so that Node.js's default unhandled-rejection behavior terminates the host process.

vm2 versions from 3.9.6 before 3.11.7 fail to properly restrict access to accessor properties on frozen objects, allowing sandboxed scripts to bypass vm.freeze() and vm.readonly() protections. Attackers can use Object.getOwnPropertyDescriptor() or __lookupSetter__() to extract and invoke host object setters directly, mutating properties the embedder explicitly marked read-only.

In vm2 versions ≤ 3.11.6, the VM({ timeout }) option is not enforced for code executed outside the synchronous VM#run() call. Sandboxed code can register a FinalizationRegistry callback and, after dropping an object reference, block the host event loop indefinitely, causing denial of service.

vm2 is a sandbox for running untrusted Node.js code. In versions <= 3.11.7, NodeVM exposes the host util module to the sandbox as an unfiltered shallow copy, and the deprecated sys builtin is exposed through the generic builtin loader. On Node.js >= 22.9 this hands sandboxed code util.getCallSites(), which returns the host process's full call stack, including absolute file paths, function names, and line numbers. Fixed in vm2 3.11.8.

vm2 prior to version 3.11.6 has a vulnerability where the bufferAllocLimit enforcement does not cover Buffer.concat(list, totalLength) or Buffer.from(arrayLike) with an attacker-controlled length, allowing sandbox code to perform large synchronous host external-memory allocations that bypass the configured cap and can exhaust the host process.

In versions prior to 3.11.4, the vm2 library has a vulnerability in the BaseHandler.set method that ignores the receiver parameter and incorrectly writes to the target object. This leads to inherited properties leaking to the host object, creating an attack vector for dangerous cross-realm Symbol keys.

vm2 is an open source vm/sandbox for Node.js. Prior to version 3.11.4, NodeVM exposes some process-wide observability builtins that can be used by sandboxed code to observe host application data.

vm2 is an open source vm/sandbox for Node.js. Prior to version 3.11.4, NodeVM allowed excluding public network modules, but underscored internal HTTP modules like _http_client and _http_server were not blocked, enabling HTTP requests despite the exclusion of public modules.

vm2 is an open source vm/sandbox for Node.js. Prior to version 3.11.4, Symbol.for override in setup-sandbox.js only intercepts 2 of 9 dangerous Node.js cross-realm symbols, allowing for the acquisition of real cross-realm symbols and control over host-side behavior.

A vulnerability in the vm2 library for Node.js prior to version 3.11.0 allows sandboxed code to call Buffer.alloc() with an arbitrary size, allocating memory directly on the host heap. Because Buffer.alloc is a synchronous C++ native call, vm2's timeout option cannot interrupt it, enabling a single request to exhaust host memory and crash the process.

In vm2 prior to 3.11.0, the code transformer has a performance optimization that skips AST analysis when the code does not contain catch, import, or async keywords. This fast-path bypass allows sandboxed code to directly access the internal VM2_INTERNAL_STATE_DO_NOT_USE_OR_PROGRAM_WILL_FAIL variable, exposing internal security functions (handleException, wrapWith, import). This vulnerability is fixed in 3.11.0.

In vm2 prior to 3.11.0, the CallSite wrapper class (intended as a safe wrapper for V8's native CallSite) blocks getThis() and getFunction() to prevent host object leakage, but allows getFileName() to return unsanitized host absolute paths. Any sandboxed code can extract the full directory structure, library paths, and framework versions of the host server. This vulnerability is fixed in 3.11.0.

A sandbox escape vulnerability in vm2 before 3.11.0 allows sandboxed code to crash the host Node.js process via a Promise constructor triggering an unhandled rejection. The issue affects version 3.10.5 and is fixed in 3.11.0.

In vm2 prior to 3.11.0, a sandbox boundary violation allows host object identity to cross into the sandbox through host Promise resolution. When a host-side Promise that resolves to a host object is exposed to the sandbox, the value delivered to the sandbox .then() callback preserves host identity, allowing the sandbox to interact with the host object directly, including performing identity checks using host-side WeakMap and mutating host object state.

In vm2 3.10.5, the NodeVM require.root path restriction can be bypassed using filesystem symlinks, allowing sandboxed code to load modules from outside the allowed root directory in host context. Because path validation uses path.resolve() (which does not dereference symlinks) but module loading uses Node's native require() (which does), an attacker can load arbitrary host-realm modules and achieve remote code execution.