vm2@3.9.1

vm2 is a sandbox that can run untrusted code with whitelisted Node's built-in modules.

  • latest version

    3.11.5

  • latest non vulnerable version

  • first published

    12 years ago

  • latest version published

    1 months ago

  • licenses detected

  • Direct Vulnerabilities

    Known vulnerabilities in the vm2 package. This does not include vulnerabilities belonging to this package’s dependencies.

    Fix vulnerabilities automatically

    Snyk's AI Trust Platform automatically finds the best upgrade path and integrates with your development workflows. Secure your code at zero cost.

    Fix for free
    VulnerabilityVulnerable Version
    • H
    Incomplete List of Disallowed Inputs

    vm2 is a sandbox that can run untrusted code with whitelisted Node's built-in modules.

    Affected versions of this package are vulnerable to Incomplete List of Disallowed Inputs via the NodeVM builtin allowlist in lib/builtin.js. An attacker can read host-process state by supplying a sandbox require() for diagnostics_channel, async_hooks, perf_hooks, or v8, then using their observability APIs to exfiltrate HTTP request headers, async-context data, performance marks, or the full V8 heap. This affects sandboxes that expose builtin: ['*'] or explicitly allow these modules, letting untrusted code recover secrets and internal application data that the embedder processes in the same Node.js instance.

    How to fix Incomplete List of Disallowed Inputs?

    Upgrade vm2 to version 3.11.4 or higher.

    <3.11.4
    • H
    Protection Mechanism Failure

    vm2 is a sandbox that can run untrusted code with whitelisted Node's built-in modules.

    Affected versions of this package are vulnerable to Protection Mechanism Failure through the NodeVM builtin wildcard expansion in lib/builtin.js. An attacker can load Node’s private underscored network and stream builtins by supplying builtin: ['*', '-http', '-https', '-net', '-dgram', '-tls', '-dns', '-http2'] and then requiring modules such as _http_client, _http_server, or _tls_wrap. This lets sandboxed code make outbound HTTP requests or open listening sockets despite the embedder’s network exclusions, exposing localhost services, cloud metadata endpoints, and internal admin interfaces to requests originating from the host process.

    How to fix Protection Mechanism Failure?

    Upgrade vm2 to version 3.11.4 or higher.

    <3.11.4
    • C
    Improperly Controlled Modification of Dynamically-Determined Object Attributes

    vm2 is a sandbox that can run untrusted code with whitelisted Node's built-in modules.

    Affected versions of this package are vulnerable to Improperly Controlled Modification of Dynamically-Determined Object Attributes via the BaseHandler.set trap in lib/bridge.js. An attacker can mutate host-realm objects or install attacker-controlled hooks by writing through an inherited object or a forged Reflect.set receiver, causing sandbox-supplied values to be written to the wrapped host object instead of the intended receiver. This lets sandbox code pollute host-side properties on any embedder-exposed object, including dispatch slots used by host code, potentially leading to host-side code execution when the polluted property is later consumed.

    How to fix Improperly Controlled Modification of Dynamically-Determined Object Attributes?

    Upgrade vm2 to version 3.11.4 or higher.

    <3.11.4
    • C
    Improper Control of Dynamically-Managed Code Resources

    vm2 is a sandbox that can run untrusted code with whitelisted Node's built-in modules.

    Affected versions of this package are vulnerable to Improper Control of Dynamically-Managed Code Resources through the WebAssembly.promising and WebAssembly.Suspending JSPI APIs in lib/setup-sandbox.js. An attacker can reach host-realm Promise.prototype methods from a sandbox-visible promise, install an attacker-controlled constructor getter, and drive Promise.prototype.finally to hand a raw host error to sandbox code by instantiating a JSPI-enabled wasm module and triggering a rejection. That raw host object lets the attacker recover the host Function constructor and execute code in the host realm, breaking out of the VM and exposing the underlying process.

    How to fix Improper Control of Dynamically-Managed Code Resources?

    Upgrade vm2 to version 3.11.4 or higher.

    <3.11.4
    • C
    Improper Control of Dynamically-Managed Code Resources

    vm2 is a sandbox that can run untrusted code with whitelisted Node's built-in modules.

    Affected versions of this package are vulnerable to Improper Control of Dynamically-Managed Code Resources through the lib/bridge.js apply trap and thisEnsureThis proto-walk. An attacker can obtain host prototype-mutating intrinsics such as Object.prototype.__proto__ and invoke them with a wrapped host object as this by sending crafted call/apply/bind or Reflect.apply/Reflect.construct indirections, severing a host prototype chain and causing a later host error to be returned to sandbox code unwrapped. Once the bridge stops recognizing the tampered host object, sandbox code can read e.constructor.constructor to reach host Function and execute arbitrary host-side code, breaking out of the VM and exposing the underlying process.

    How to fix Improper Control of Dynamically-Managed Code Resources?

    Upgrade vm2 to version 3.11.4 or higher.

    <3.11.4
    • C
    Improper Control of Dynamically-Managed Code Resources

    vm2 is a sandbox that can run untrusted code with whitelisted Node's built-in modules.

    Affected versions of this package are vulnerable to Improper Control of Dynamically-Managed Code Resources through the NodeVM constructor in lib/nodevm.js. An attacker can obtain host code execution by creating a nested VM with nesting: true and an omitted or falsy require value, then using the injected vm2 builtin to spawn an inner NodeVM with attacker-chosen require settings and reach child_process. The vulnerable configuration produces a NESTING_OVERRIDE-only resolver whose sole builtin is vm2, so sandboxed code can load vm2 even when the outer VM was intended to deny requires. This breaks the user's expectation that a nested sandbox remains constrained and can lead to full compromise of the host process.

    How to fix Improper Control of Dynamically-Managed Code Resources?

    Upgrade vm2 to version 3.11.4 or higher.

    <3.11.4
    • C
    Incomplete List of Disallowed Inputs

    vm2 is a sandbox that can run untrusted code with whitelisted Node's built-in modules.

    Affected versions of this package are vulnerable to Incomplete List of Disallowed Inputs through Symbol.for handling in lib/setup-sandbox.js and the bridge write traps in lib/bridge.js. An attacker can install host-side hooks or alter host object behavior by supplying nodejs.* symbol keys such as nodejs.util.promisify.custom, stream brand symbols, or webstream symbols on a bridge-exposed host object. The sandbox-side symbol registry exposed real cross-realm Node internal symbols for keys outside the original allowlist, and the bridge forwarded dangerous symbol keys through set, defineProperty, and deleteProperty without rejecting them. This lets sandbox code hijack util.promisify callbacks, or interfere with webstream error handling on mutable host objects exposed to the VM.

    How to fix Incomplete List of Disallowed Inputs?

    Upgrade vm2 to version 3.11.4 or higher.

    <3.11.4
    • C
    Improper Control of Dynamically-Managed Code Resources

    vm2 is a sandbox that can run untrusted code with whitelisted Node's built-in modules.

    Affected versions of this package are vulnerable to Improper Control of Dynamically-Managed Code Resources via the localPromise constructor in lib/setup-sandbox.js. An attacker can obtain a host-realm RangeError and reach the host Function constructor by supplying a Promise subclass with a malicious Symbol.species getter and triggering the swallow-tail path with new FakePromise(r => r()). The cached host Promise.prototype.then used in that constructor resolves its downstream child through the species protocol, so the attacker-controlled species constructor receives V8’s internal (resolve, reject) capability and can rebind rejection handling to a sandbox collector. When a host error is later delivered through that chain, the raw host object is exposed to sandbox code, enabling ex.constructor.constructor("return process")() and arbitrary command execution.

    How to fix Improper Control of Dynamically-Managed Code Resources?

    Upgrade vm2 to version 3.11.4 or higher.

    <3.11.4
    • C
    Incomplete List of Disallowed Inputs

    vm2 is a sandbox that can run untrusted code with whitelisted Node's built-in modules.

    Affected versions of this package are vulnerable to Incomplete List of Disallowed Inputs via the builtin allowlist handling in lib/builtin.js. An attacker can reach host code by requiring process and calling getBuiltinModule('child_process'), or by requiring inspector/promises and using Session().post('Runtime.evaluate', ...) to execute JavaScript in the host realm. This lets sandboxed code bypass the intended built-in restrictions and obtain host process execution capabilities, leading to arbitrary command execution and full compromise of the sandboxed application.

    How to fix Incomplete List of Disallowed Inputs?

    Upgrade vm2 to version 3.11.4 or higher.

    <3.11.4
    • C
    Arbitrary Code Injection

    vm2 is a sandbox that can run untrusted code with whitelisted Node's built-in modules.

    Affected versions of this package are vulnerable to Arbitrary Code Injection through the yield* iterator inside an async generator. An attacker can execute arbitrary commands on the host system by escaping the sandbox environment.

    How to fix Arbitrary Code Injection?

    Upgrade vm2 to version 3.11.3 or higher.

    <3.11.3
    • C
    Arbitrary Code Injection

    vm2 is a sandbox that can run untrusted code with whitelisted Node's built-in modules.

    Affected versions of this package are vulnerable to Arbitrary Code Injection despite the recently introduced neutralizeArraySpeciesBatch helper in lib/bridge.js. An attacker can execute arbitrary code by installing a setter on Array.prototype[N] and then triggering a host call with a sandbox array argument, causing the bridge to append its saved-state record through ordinary indexed assignment and hand the attacker a record containing a host-realm proxy. From that leaked proxy, attacker-controlled code can reach the host Function constructor and obtain the host process, escaping the sandbox and running commands in the host environment.

    How to fix Arbitrary Code Injection?

    Upgrade vm2 to version 3.11.2 or higher.

    <3.11.2
    • M
    Improper Isolation or Compartmentalization

    vm2 is a sandbox that can run untrusted code with whitelisted Node's built-in modules.

    Affected versions of this package are vulnerable to Improper Isolation or Compartmentalization through the setupSandboxScript bootstrap in lib/vm.js and lib/setup-sandbox.js. An attacker can read the sandbox’s VM2_INTERNAL_STATE_DO_NOT_USE_OR_PROGRAM_WILL_FAIL object by supplying computed property accesses such as globalThis['VM2_INTERNAL_STATE_DO_NOT_USE_OR_PROGRAM_WILL_FAIL'], Reflect.get, descriptor APIs, or own-property enumeration. This exposes the live internal state object to sandboxed code, including helper methods such as handleException and wrapWith, breaking the sandbox’s protection against direct access to vm2 internals and enabling further abuse of those exposed primitives.

    Notes: This is a complementary fix for CVE-2026-44003

    How to fix Improper Isolation or Compartmentalization?

    Upgrade vm2 to version 3.11.2 or higher.

    <3.11.2
    • H
    Symlink Attack

    vm2 is a sandbox that can run untrusted code with whitelisted Node's built-in modules.

    Affected versions of this package are vulnerable to Symlink Attack via the isPathAllowed path check in lib/resolver-compat.js. An attacker can execute code outside the configured require.root by placing or using a symlink inside the allowed root and causing require() to load it. The resolver compares a lexically resolved filename against the configured root with a string prefix check, while Node’s native module loader follows symlinks to the target path. In context: 'host', this lets an attacker run outside-root modules with host privileges, leading to remote code execution and compromise of the host process.

    How to fix Symlink Attack?

    Upgrade vm2 to version 3.11.0 or higher.

    <3.11.0
    • M
    Improper Isolation or Compartmentalization

    vm2 is a sandbox that can run untrusted code with whitelisted Node's built-in modules.

    Affected versions of this package are vulnerable to Improper Isolation or Compartmentalization through the transformer fast-path in the source instrumentation logic. An attacker can expose the internal VM state and reach the wrapWith/handleException/import-related leak by supplying JavaScript that references VM2_INTERNAL_STATE_DO_NOT_USE_OR_PROGRAM_WILL_FAIL with Unicode escape sequences such as \u0056 or \u{56} so the raw substring check misses it.

    How to fix Improper Isolation or Compartmentalization?

    Upgrade vm2 to version 3.11.0 or higher.

    <3.11.0
    • M
    Improper Isolation or Compartmentalization

    vm2 is a sandbox that can run untrusted code with whitelisted Node's built-in modules.

    Affected versions of this package are vulnerable to Improper Isolation or Compartmentalization through the globalPromise.prototype.then onFulfilled wrapper in the Promise bridge. An attacker can supply a host Promise that resolves to an unmapped host object, such as an Object.create(null) instance or another host-realm class vm2 does not proto-map, and then invoke .then() from the sandbox to receive that object unwrapped. If the resolved value contains attacker-controlled methods, those methods execute in the host realm without passing through the bridge, allowing the attacker to run host-side code and break the isolation expected by the user.

    How to fix Improper Isolation or Compartmentalization?

    Upgrade vm2 to version 3.11.0 or higher.

    <3.11.0
    • M
    Information Exposure

    vm2 is a sandbox that can run untrusted code with whitelisted Node's built-in modules.

    Affected versions of this package are vulnerable to Information Exposure via the sandbox CallSite handling. An attacker can leak absolute host filesystem paths by causing error.stack or getEvalOrigin() to run on sandbox frames, exposing host-realm filenames embedded in stack traces and eval-origin strings to sandbox code.

    How to fix Information Exposure?

    Upgrade vm2 to version 3.11.0 or higher.

    <3.11.0
    • H
    Allocation of Resources Without Limits or Throttling

    vm2 is a sandbox that can run untrusted code with whitelisted Node's built-in modules.

    Affected versions of this package are vulnerable to Allocation of Resources Without Limits or Throttling through the Buffer.alloc family in lib/setup-sandbox.js. An attacker can crash the host process by supplying a large allocation size to Buffer.alloc, Buffer.allocUnsafe, Buffer.allocUnsafeSlow, or the deprecated Buffer(N) / new Buffer(N) forms inside sandboxed code. These calls execute as a single synchronous host C++ allocation, so a small sandbox payload can force a large RSS spike that exhausts memory in constrained deployments such as containers or serverless runtimes.

    How to fix Allocation of Resources Without Limits or Throttling?

    Upgrade vm2 to version 3.11.0 or higher.

    <3.11.0
    • C
    Uncaught Exception

    vm2 is a sandbox that can run untrusted code with whitelisted Node's built-in modules.

    Affected versions of this package are vulnerable to Uncaught Exception through the Promise constructor when an unhandled rejection propagates from the sandboxed environment to the host process. An attacker can cause the host process to crash by executing code that triggers an unhandled rejection, such as by setting Error.name to a Symbol() and accessing .stack within the executor function. This can be exploited remotely via a single crafted request, resulting in a persistent denial-of-service condition for all users.

    How to fix Uncaught Exception?

    Upgrade vm2 to version 3.11.0 or higher.

    <3.11.0
    • C
    Arbitrary Code Injection

    vm2 is a sandbox that can run untrusted code with whitelisted Node's built-in modules.

    Affected versions of this package are vulnerable to Arbitrary Code Injection through the proxy trap methods in createBridge in the bridge handler code. An attacker can leak a handler using util.inspect({showProxy:true}) and invoke its trap methods directly with a forged target, then walk the host prototype chain to recover privileged symbols and achieve code execution. This enables sandbox escape and lets untrusted code execute with the privileges of the host process.

    How to fix Arbitrary Code Injection?

    Upgrade vm2 to version 3.11.0 or higher.

    <3.11.0
    • C
    Arbitrary Code Injection

    vm2 is a sandbox that can run untrusted code with whitelisted Node's built-in modules.

    Affected versions of this package are vulnerable to Arbitrary Code Injection through the lib/bridge.js value-conversion paths. An attacker can extract the host Symbol.for('nodejs.util.inspect.custom') or Symbol.for('nodejs.rejection') by calling host reflection APIs on Buffer.prototype and then using that symbol as a computed property key to trigger host-side util.inspect or rejection handling with attacker-controlled callbacks. The vulnerable bridge passes raw host symbol primitives into sandbox code from host return values, iterator results, descriptor objects, and throw paths, allowing the dangerous symbol to survive into plain sandbox objects and be reused as a live key. In the affected VM environment, this leads to sandbox escape and arbitrary code execution in the host process.

    Note: Constructor access was partially blocked in version 3.10.5, but this bypasses the protection introduced there.

    How to fix Arbitrary Code Injection?

    Upgrade vm2 to version 3.11.0 or higher.

    <3.11.0
    • C
    Arbitrary Code Injection

    vm2 is a sandbox that can run untrusted code with whitelisted Node's built-in modules.

    Affected versions of this package are vulnerable to Arbitrary Code Injection through the inspect function. An attacker can execute arbitrary commands on the host system by escaping the sandbox environment.

    How to fix Arbitrary Code Injection?

    Upgrade vm2 to version 3.11.0 or higher.

    <3.11.0
    • C
    Arbitrary Code Injection

    vm2 is a sandbox that can run untrusted code with whitelisted Node's built-in modules.

    Affected versions of this package are vulnerable to Arbitrary Code Injection via the SuppressedError. An attacker can execute arbitrary code outside the intended sandbox environment by leveraging this flaw.

    How to fix Arbitrary Code Injection?

    Upgrade vm2 to version 3.11.0 or higher.

    <3.11.0
    • C
    Arbitrary Code Injection

    vm2 is a sandbox that can run untrusted code with whitelisted Node's built-in modules.

    Affected versions of this package are vulnerable to Arbitrary Code Injection through the vm2.run function. An attacker can execute arbitrary commands on the host system by escaping the sandbox environment and gaining access to the host process object.

    How to fix Arbitrary Code Injection?

    Upgrade vm2 to version 3.10.5 or higher.

    <3.10.5
    • C
    Arbitrary Code Injection

    vm2 is a sandbox that can run untrusted code with whitelisted Node's built-in modules.

    Affected versions of this package are vulnerable to Arbitrary Code Injection through the __lookupGetter__ method and improper context isolation. An attacker can execute arbitrary commands on the host system by escaping the sandbox and leveraging host context methods.

    How to fix Arbitrary Code Injection?

    Upgrade vm2 to version 3.11.0 or higher.

    <3.11.0
    • H
    Improper Control of Dynamically-Managed Code Resources

    vm2 is a sandbox that can run untrusted code with whitelisted Node's built-in modules.

    Affected versions of this package are vulnerable to Improper Control of Dynamically-Managed Code Resources due to the unsafe usage of the .call() with globalPromise.prototype.then callback function. An attacker can execute arbitrary code outside the intended sandbox by overwriting Function.prototype.call inside the sandbox that bypass the intended security controls.

    Note:

    This issue can be mitigated by migrating to 'isolated-vm' for stronger isolation based on V8 Isolates and using OS-level isolation (Docker, gVisor, Firecracker) instead of application-level sandboxes.

    How to fix Improper Control of Dynamically-Managed Code Resources?

    Upgrade vm2 to version 3.10.2 or higher.

    <3.10.2
    • C
    Remote Code Execution (RCE)

    vm2 is a sandbox that can run untrusted code with whitelisted Node's built-in modules.

    Affected versions of this package are vulnerable to Remote Code Execution (RCE) due to insufficient checks which allow an attacker to escape the sandbox.

    Note:

    According to the maintainer, the security issue cannot be properly addressed and the library will be discontinued.

    How to fix Remote Code Execution (RCE)?

    Upgrade vm2 to version 3.10.0 or higher.

    <3.10.0
    • C
    Remote Code Execution (RCE)

    vm2 is a sandbox that can run untrusted code with whitelisted Node's built-in modules.

    Affected versions of this package are vulnerable to Remote Code Execution (RCE) such that the Promise handler sanitization can be bypassed, allowing attackers to escape the sandbox.

    Note:

    According to the maintainer, the security issue cannot be properly addressed and the library will be discontinued.

    How to fix Remote Code Execution (RCE)?

    Upgrade vm2 to version 3.10.0 or higher.

    <3.10.0
    • C
    Sandbox Bypass

    vm2 is a sandbox that can run untrusted code with whitelisted Node's built-in modules.

    Affected versions of this package are vulnerable to Sandbox Bypass by abusing an unexpected creation of a host object based on the maliciously crafted specification of Proxy. Exploiting this vulnerability allows an attacker to gain remote code execution rights on the host running the sandbox via the Function constructor.

    How to fix Sandbox Bypass?

    Upgrade vm2 to version 3.9.18 or higher.

    <3.9.18
    • M
    Improper Neutralization of Special Elements in Output Used by a Downstream Component ('Injection')

    vm2 is a sandbox that can run untrusted code with whitelisted Node's built-in modules.

    Affected versions of this package are vulnerable to Improper Neutralization of Special Elements in Output Used by a Downstream Component ('Injection') via the inspect method of vm.js, which allows write permissions. Exploiting this vulnerability allows an attacker to edit options for the console.log command.

    How to fix Improper Neutralization of Special Elements in Output Used by a Downstream Component ('Injection')?

    Upgrade vm2 to version 3.9.18 or higher.

    <3.9.18
    • C
    Improper Handling of Exceptional Conditions

    vm2 is a sandbox that can run untrusted code with whitelisted Node's built-in modules.

    Affected versions of this package are vulnerable to Improper Handling of Exceptional Conditions due to allowing attackers to raise an unsanitized host exception inside handleException() which can be used to escape the sandbox and run arbitrary code in host context.

    How to fix Improper Handling of Exceptional Conditions?

    Upgrade vm2 to version 3.9.17 or higher.

    <3.9.17
    • C
    Sandbox Escape

    vm2 is a sandbox that can run untrusted code with whitelisted Node's built-in modules.

    Affected versions of this package are vulnerable to Sandbox Escape. There exists a vulnerability in source code transformer (exception sanitization logic), allowing attackers to bypass handleException() and leak unsanitized host exceptions which can be used to escape the sandbox and run arbitrary code in host context.

    How to fix Sandbox Escape?

    Upgrade vm2 to version 3.9.16 or higher.

    <3.9.16
    • C
    Sandbox Escape

    vm2 is a sandbox that can run untrusted code with whitelisted Node's built-in modules.

    Affected versions of this package are vulnerable to Sandbox Escape due to improper handling of host objects passed to Error.prepareStackTrace in case of unhandled async errors.

    How to fix Sandbox Escape?

    Upgrade vm2 to version 3.9.15 or higher.

    <3.9.15
    • C
    Arbitrary Code Execution

    vm2 is a sandbox that can run untrusted code with whitelisted Node's built-in modules.

    Affected versions of this package are vulnerable to Arbitrary Code Execution due to the usage of prototype lookup for the WeakMap.prototype.set method. Exploiting this vulnerability leads to access to a host object and a sandbox compromise.

    How to fix Arbitrary Code Execution?

    Upgrade vm2 to version 3.9.10 or higher.

    <3.9.10
    • C
    Sandbox Bypass

    vm2 is a sandbox that can run untrusted code with whitelisted Node's built-in modules.

    Affected versions of this package are vulnerable to Sandbox Bypass via indirect access to host.Object during preparation of stacktraces, which can lead to execution of arbitrary code on the host machine.

    How to fix Sandbox Bypass?

    Upgrade vm2 to version 3.9.11 or higher.

    <3.9.11
    • C
    Sandbox Bypass

    vm2 is a sandbox that can run untrusted code with whitelisted Node's built-in modules.

    Affected versions of this package are vulnerable to Sandbox Bypass via direct access to host error objects generated by node internals during generation of a stacktraces, which can lead to execution of arbitrary code on the host machine.

    How to fix Sandbox Bypass?

    Upgrade vm2 to version 3.9.6 or higher.

    <3.9.6
    • C
    Sandbox Bypass

    vm2 is a sandbox that can run untrusted code with whitelisted Node's built-in modules.

    Affected versions of this package are vulnerable to Sandbox Bypass via a Prototype Pollution attack vector, which can lead to execution of arbitrary code on the host machine.

    PoC

    const {VM} = require("vm2");
    let vmInstance = new VM();
    
    let code = `    
        res = eval('import(\\'./foo.js\\');')    
        res.__proto__.__proto__.polluted = res.__proto__.__proto__.toString.constructor("return this")().process.mainModule.require("child_process").execSync("touch HACKED").toString();
    `;
    vmInstance.run(code);
    console.log(polluted);
    

    How to fix Sandbox Bypass?

    Upgrade vm2 to version 3.9.4 or higher.

    <3.9.4