Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
77 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
NodeVM's 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. Severity High (CVSS 3.1: 8.5) CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:H/A:H - Attack Vector: Network — sandboxed code is typically received from external sources (user-submitted scripts, plugin code) - Attack Complexity: High — requires symlinks inside the allowed root that point outside it; common with pnpm, npm workspaces, and npm link but not guaranteed in all deployments - Privileges Required: Low — attacker needs only the ability to submit code to the sandbox, which is the intended use case - User Interaction: None - Scope: Changed — the vulnerability is in the sandbox…
Recommended action: Upgrade to 3.11.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
vm2's 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 VM2INTERNALSTATEDONOTUSEORPROGRAMWILLFAIL variable, which exposes internal security functions (handleException, wrapWith, import). Details In lib/transformer.js:55-57, a regex check /\b(?:catch|import|async)\b/ determines whether AST transformation is needed. If the code does not contain any of these keywords, the transformer returns the code unmodified. When the fast-path is taken: 1. INTERNALSTATENAME identifier check is bypassed: The AST visitor that blocks access to VM2INTERNALSTATEDONOTUSEORPROGRAMWILLFAIL never runs 2. with statement instrumentation is bypassed: with() statements are not wrapped with wrapWith(), enabling scope manipulation 3. The internal state object exposes: handleException(e), wrapWith(x), import(what) While these methods are currently…
Recommended action: Upgrade to 3.11.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
vm2's 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. Details In lib/setup-sandbox.js:436-466, the CallSite class overrides getThis() and getFunction() with undefined to prevent host object references from leaking into the sandbox. However, the following methods pass through unsanitized values from the original V8 CallSite object: - getFileName() — returns host absolute paths like /app/nodemodules/vm2/lib/vm.js - getLineNumber(), getColumnNumber() — exact source locations - getFunctionName(), getMethodName(), getTypeName() — internal function names Two exploitation paths exist: 1. Default error.stack: new Error().stack includes host frame paths in the formatted string 2. Custom prepareStackTrace:…
Recommended action: Upgrade to 3.11.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A sandbox boundary violation in vm2 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. This allows the sandbox to interact with the host object directly, including: - Performing identity checks using host-side WeakMap - Mutating host object state from inside the sandbox This behavior occurs because the Promise fulfillment wrapper uses ensureThis() instead of the stronger cross-realm conversion path (from() / proxy wrapping). If no prototype mapping is found, ensureThis() returns the original object. As a result, objects resolved by host Promises can cross the sandbox boundary without proper isolation. --- Details In setup-sandbox.js, vm2 wraps Promise.prototype.then: js globalPromise.prototype.then = function then(onFulfilled, onRejected) { resetPromiseSpecies(this); if (typeof…
Recommended action: Upgrade to 3.11.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Sandboxed code can call Buffer.alloc() with an arbitrary size to allocate memory directly on the host heap. Because Buffer.alloc is a synchronous C++ native call, vm2's timeout option cannot interrupt it. A single request can exhaust host memory and crash the process with a FATAL ERROR: Reached heap limit. Details In lib/vm.js:58, Buffer is exposed to the sandbox through the HOST object. The bridge proxy (lib/bridge.js) passes Buffer.alloc() calls to the host without any size validation. Key technical distinction from regular JavaScript memory exhaustion (e.g., while(true) a.push(...)): - JavaScript loops: V8 can interrupt via timeout — vm2's timeout option works - Buffer.alloc(N): Executes as a single synchronous C++ call — V8 timeout has no opportunity to interrupt This means: 1. timeout: 5000 does NOT protect against this attack 2. A single call allocates the entire requested size at once 3. In memory-constrained environments (Docker, Lambda, Kubernetes pods), this causes…
Recommended action: Upgrade to 3.11.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A sandbox escape vulnerability in vm2 v3.10.5 allows any sandboxed code to crash the host Node.js process via a single Promise constructor that triggers an unhandled rejection propagating to the host. The fix for CVE-2026-22709 (v3.10.2) only sanitized the onRejected callback in .then() and .catch() overrides and did not address the executor-to-unhandledRejection path. Details When sandboxed code creates a Promise whose executor sets Error.name to a Symbol() and then accesses .stack, V8's internal FormatStackTrace (C++) attempts Symbol.toString(), which throws a host-realm TypeError. Because this error originates inside the Promise executor and no .catch() handler is attached, it becomes an unhandled rejection that propagates to the host process. - lib/setup-sandbox.js:38 — localPromise wraps the native Promise constructor but does not wrap the executor in try-catch. - lib/setup-sandbox.js:165-230 — resetPromiseSpecies and the .then()/.catch() overrides sanitize the…
Recommended action: Upgrade to 3.11.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
NodeVM's builtin allowlist can be bypassed when the module builtin is allowed (including via the '' wildcard). The module builtin exposes Node's Module.load(), which loads any module by name directly in the host context, completely bypassing vm2's builtin restriction. This allows sandboxed code to load excluded builtins like childprocess and achieve remote code execution. Severity Critical (CVSS 3.1: 9.9) CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H - Attack Vector: Network — sandboxed code is typically received from external sources (user-submitted scripts, plugin code) - Attack Complexity: Low — no special conditions required; ['', '-childprocess'] is a common, documented pattern - Privileges Required: Low — attacker needs only the ability to submit code to the sandbox, which is the intended use case - User Interaction: None - Scope: Changed — escape from sandbox boundary to host system - Confidentiality Impact: High — arbitrary command execution on the host - Integrity…
Recommended action: Upgrade to 3.11.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
vm2's bridge exposes mutable proxies for real host-realm intrinsic prototypes and then forwards sandbox writes into the underlying host objects with otherReflectSet() and otherReflectDefineProperty(), which lets attacker-controlled JavaScript running in a default VM or inherited NodeVM mutate shared host Object.prototype, Array.prototype, and Function.prototype from inside the sandbox. Details BaseHandler.apply() unwraps sandbox-controlled receivers and arguments with otherFromThis() / otherFromThisArguments() and then directly invokes the real host function with ret = otherReflectApply(object, context, args), so any default-exposed host function that can surface a prototype getter becomes a prototype-walking primitive (lib/bridge.js:665-676). BaseHandler.get() special-cases proto and returns the host-side descriptor or proxy target prototype, which is enough for the attacker to reuse the host lookupGetter('proto') accessor repeatedly until the walk lands on host…
Recommended action: Upgrade to 3.11.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
It is possible to obtain the host Object, https://github.com/patriksimek/vm2/commit/ebcfe94ad2f864f0bc35e78cff1d921107cfd160 added some protections, but the implementation is incomplete. Details There are various ways to use the host Object, to escape the sandbox, one example would be using HostObject.getOwnPropertySymbols to obtain Symbol(nodejs.util.inspect.custom) PoC Impact Sandbox Escape - RCE
Recommended action: Upgrade to 3.11.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
It is possible to reach BaseHandler.getPrototypeOf, which can be used to get arbitrary prototypes Details https://github.com/patriksimek/vm2/blob/408fc855f1cc1bbc2985b029465ee0e732ada433/lib/bridge.js#L655-L658 BaseHandler can be reached via util.inspect (same as https://github.com/patriksimek/vm2/commit/57971fa423abeb66f09e47e18102986549474ca8) PoC Impact Sandbox Escape - RCE
Recommended action: Upgrade to 3.11.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Full sandbox escape with arbitrary code execution. Attacker code inside VM.run() obtains host process object and runs host commands with zero host cooperation. Details Confirmed on: vm2 3.10.4, Node.js v25.6.1 (x64 Linux) Trigger: Attacker-controlled code passed to VM.run() Requires: Node.js version with WebAssembly exception handling + JSTag support (tested on v25.6.1) vm2's sandbox security relies on two JavaScript-level mechanisms: (1) a code transformer that injects handleException() into JS catch clauses to wrap host-realm errors, and (2) bridge Proxies that wrap cross-context objects. Both operate entirely within JavaScript. WebAssembly's trytable instruction with a JSTag catch handler catches JavaScript exceptions at V8's C++ level — below JavaScript entirely. When an imported JS function throws a TypeError produced by Symbol-to-string coercion during stack formatting (e.name = Symbol(); e.stack), the WASM trytable catches it as an opaque externref and returns it as a…
Recommended action: Upgrade to 3.10.5 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
In vm2 v3.10.4 on Node.js v24.13.0, `SuppressedError` allows attackers to escape the sandbox and run arbitrary code. PoC ```js const { VM } = require("vm2"); const vm = new VM(); vm.run(` const ds = new DisposableStack(); ds.defer(() => { throw null; }); ds.defer(() => { const e = Error(); e.name = Symbol(); e.stack; }); try { ds.dispose(); } catch(e) { const Function = e.suppressed.constructor.constructor; const process = new Function("return process;")(); const { execSync } = process.mainModule.require("node:child_process"); execSync("echo pwned", { stdio: "inherit" }); } `); ```
Recommended action: Upgrade to 3.11.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
VM2 suffers from a sandbox breakout vulnerability through the `inspect` function. This allows attackers to write code which can escape from the VM2 sandbox and execute arbitrary commands on the host system. Details The node `inspect` method allows to log details of objects. To get to the details, the implementation unwraps proxies. The unwrapped values can be extracted using the `this.seen` of the `stylize` function. This allows to get access to the internal proxy handler of VM2 which contains the sandbox object. Since the access to the handler is itself wrapped by a VM2 proxy, accessing the sandbox object in the proxy handler will result in a wrapped sandbox object given into the sandbox. This allows to write a wrapped host object to the wrapped sandbox object and read the raw host object from the raw sandbox object bypassing the proxy bridge. PoC ```js const obj = { subarray: Buffer.prototype.inspect, slice: Buffer.prototype.slice, hexSlice:()=>'', l:{proto:…
Recommended action: Upgrade to 3.11.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The fix for https://github.com/patriksimek/vm2/security/advisories/GHSA-cchq-frgv-rjh5 is insufficient and can be circumvented allowing attackers to write code which can escape from the VM2 sandbox and execute arbitrary commands on the host system. Details The fix for https://github.com/patriksimek/vm2/security/advisories/GHSA-cchq-frgv-rjh5 introduced the function resetPromiseSpecies https://github.com/patriksimek/vm2/blob/4b009c2d4b1131c01810c1205e641d614c322a29/lib/setup-sandbox.js#L35C7-L39. This function changes the species property of promise objects back to a known value. However, it uses the function [].includes and Object.defineProperty which can be overewritten to prevent the species from being changed. PoC The following code demonstrates this issue by aquiring the host process object and executing touch pwned. Impact Attackers can perform Remote Code Execution under the assumption that the attacker can run arbitrary code execution inside the context of a vm2 sandbox.
Recommended action: Upgrade to 3.10.5 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
VM2 suffers from a sandbox breakout vulnerability. This allows attackers to write code which can escape from the VM2 sandbox and execute arbitrary commands on the host system. Details The `lookupGetter` method allows to read the getter of an object. It is special in VM2 since it will switch between the host and sandbox version of the method when passed to the other context. This allows to access getters on an object in the host context if the method is called from the host context which can be achieved by using the host `apply` method which can be accessed through `Buffer.apply`. Afterwards, this function can be used to call the host version of `lookupGetter` with `Buffer` and `proto` resulting in the prototype lookup method from the host context. With this method the hosts `Function.prototype` object can be retrieved and the host `Function` acquired through the `constructor` property which allows to create and run code in the host context. This issue was…
Recommended action: Upgrade to 3.11.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
In vm2 for version 3.10.0, Promise.prototype.then Promise.prototype.catch callback sanitization can be bypassed. This allows attackers to escape the sandbox and run arbitrary code. In lib/setup-sandbox.js, the callback function of localPromise.prototype.then is sanitized, but globalPromise.prototype.then is not sanitized. The return value of async functions is globalPromise object.
Recommended action: Upgrade to 3.10.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
In vm2 for versions up to 3.9.19, Promise handler sanitization can be bypassed, allowing attackers to escape the sandbox and run arbitrary code. Impact Remote Code Execution, assuming the attacker has arbitrary code execution primitive inside the context of vm2 sandbox. Patches None. Workarounds None. References PoC - https://gist.github.com/leesh3288/f693061e6523c97274ad5298eb2c74e9 For more information If you have any questions or comments about this advisory: - Open an issue in VM2 Thanks to Xion (SeungHyun Lee) of KAIST Hacking Lab for disclosing this vulnerability.
Recommended action: Upgrade to 3.10.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
In versions 3.9.17 and lower of vm2 it was possible to get a read-write reference to the node inspect method and edit options for console.log. Impact A threat actor can edit options for console.log. Patches This vulnerability was patched in the release of version 3.9.18 of vm2. Workarounds After creating a vm make the inspect method readonly with vm.readonly(inspect). References PoC - https://gist.github.com/arkark/c1c57eaf3e0a649af1a70c2b93b17550 For more information If you have any questions or comments about this advisory: - Open an issue in VM2 Thanks to @arkark (Takeshi Kaneko) of GMO Cybersecurity by Ierae, Inc. for disclosing this vulnerability.
Recommended action: Upgrade to 3.9.18 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A sandbox escape vulnerability exists in vm2 for versions up to 3.9.17. It abuses an unexpected creation of a host object based on the specification of Proxy. Impact A threat actor can bypass the sandbox protections to gain remote code execution rights on the host running the sandbox. Patches This vulnerability was patched in the release of version 3.9.18 of vm2. Workarounds None. References PoC - https://gist.github.com/arkark/e9f5cf5782dec8321095be3e52acf5ac For more information If you have any questions or comments about this advisory: - Open an issue in VM2 Thanks to @arkark (Takeshi Kaneko) of GMO Cybersecurity by Ierae, Inc. for disclosing this vulnerability.
Recommended action: Upgrade to 3.9.18 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
There exists a vulnerability in exception sanitization of vm2 for versions up to 3.9.16, 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. Impact A threat actor can bypass the sandbox protections to gain remote code execution rights on the host running the sandbox. Patches This vulnerability was patched in the release of version 3.9.17 of vm2. Workarounds None. References PoC - https://gist.github.com/leesh3288/381b230b04936dd4d74aaf90cc8bb244 For more information If you have any questions or comments about this advisory: - Open an issue in VM2 Thanks to Xion (SeungHyun Lee) of KAIST Hacking Lab for disclosing this vulnerability.
Recommended action: Upgrade to 3.9.17 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
There exists a vulnerability in source code transformer (exception sanitization logic) of vm2 for versions up to 3.9.15, 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. Impact A threat actor can bypass the sandbox protections to gain remote code execution rights on the host running the sandbox. Patches This vulnerability was patched in the release of version 3.9.16 of vm2. Workarounds None. References Github Issue - https://github.com/patriksimek/vm2/issues/516 PoC - https://gist.github.com/leesh3288/f05730165799bf56d70391f3d9ea187c For more information If you have any questions or comments about this advisory: - Open an issue in VM2 Thanks to Xion (SeungHyun Lee) of KAIST Hacking Lab for disclosing this vulnerability.
Recommended action: Upgrade to 3.9.16 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
vm2 was not properly handling host objects passed to Error.prepareStackTrace in case of unhandled async errors. - vm2 version: ~3.9.14 - Node version: 18.15.0, 19.8.1, 17.9.1 Impact A threat actor can bypass the sandbox protections to gain remote code execution rights on the host running the sandbox. Patches This vulnerability was patched in the release of version 3.9.15 of vm2. Workarounds None.
Recommended action: Upgrade to 3.9.15 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The package vm2 before 3.9.10 is 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.
Recommended action: Upgrade to 3.9.10 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact A threat actor can bypass the sandbox protections to gain remote code execution rights on the host running the sandbox. Patches This vulnerability was patched in the release of version 3.9.11 of vm2 Workarounds None. References Github Issue - https://github.com/patriksimek/vm2/issues/467 The file that was patched - https://github.com/patriksimek/vm2/blob/master/lib/setup-sandbox.js#L71 The commit with the patch - https://github.com/patriksimek/vm2/commit/d9a7f3cc995d3d861e1380eafb886cb3c5e2b873#diff-b1a515a627d820118e76d0e323fe2f0589ed50a1eacb490f6c3278fe3698f164 For more information If you have any questions or comments about this advisory: Open an issue in VM2
Recommended action: Upgrade to 3.9.11 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
This affects the package vm2 before 3.6.11. It is possible to trigger a RangeError exception from the host rather than the "sandboxed" context by reaching the stack call limit with an infinite recursion. The returned object is then used to reference the mainModule property of the host code running the script allowing it to spawn a childprocess and execute arbitrary code.
Recommended action: Upgrade to 3.6.11 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.