Patriksimek
Monthly
Denial of service in vm2 sandboxes before 3.12.2 allows an untrusted script running via VM.run to terminate the host Node.js process. The BaseHandler construct trap returns Reflect.construct's result without calling markHostPromiseHandled() the way the adjacent apply trap does, so if an embedder exposes a constructable host function whose constructor returns a resident rejected Promise, invoking it with `new` and discarding the result lets the rejection cross the sandbox bridge unhandled; under Node's default strict unhandled-rejection policy this is promoted to a process-terminating uncaught exception. The bug is unauthenticated in the sense that the attacker only needs to submit script code (PR:N/UI:N), but exploitation is conditional: it requires a specific embedder integration exposing such a constructable Promise-returning host constructor, which is the AT:P precondition and is not vm2 default behavior; no public exploit code was identified at time of analysis and the issue is not in CISA KEV.
Sandbox escape leading to arbitrary host code execution in vm2 (the npm sandbox library, CPE cpe:2.3:a:patriksimek:vm2) affects all versions before 3.12.2 when NodeVM is configured with a custom `require.external` resolver and `context: 'host'`. Because the resolver records the allowed module directory as an unanchored prefix pattern, untrusted guest code can require an allowlisted package (e.g. `foo`) and then require a non-allowlisted sibling sharing that prefix (e.g. `node_modules/foo2/index.js`), whose top-level code is loaded via `hostRequire` in the host process before `vm.readonly` wrapping, yielding code execution outside the sandbox. Exploitation requires the non-default host-passthrough external-resolver deployment plus a prefix-sharing sibling package, but needs no authentication or user interaction (CVSS:4.0 9.5, AT:P/PR:N/UI:N; assessed CVSS:3.1 AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:H); no public exploit code was identified at time of analysis and the flaw is not in CISA KEV, though the vendor has published patched commits and version 3.12.2.
Sandbox escape in vm2 3.12.0 and earlier allows unauthenticated remote attackers who can supply JavaScript to an application embedding vm2's VM or NodeVM to break out of the sandbox and execute arbitrary code on the host, provided the embedder exposes at least one host API returning a host-realm (native) Promise whose rejection value is host-pivotable - the advisory cites a host process object as the example. The flaw is an incomplete rejection-sanitization failure in lib/bridge.js: the sandbox-side Symbol.species and .then neutralization is installed only on the sandbox intrinsic Promise.prototype, so it never applies to host Promises, letting sandboxed code overwrite p.constructor[Symbol.species] and call p.then() without an onRejected handler, after which V8's internal Thrower re-throws the raw host rejection value into an attacker-controlled resolve/reject closure, bypassing handleException and hostPromiseSanitizeReject and yielding an unsanitized, fully functional bridge proxy of the host object. No public exploit identified at time of analysis, but the CVSS 4.0 base score is 10.0 and the issue is fixed in 3.12.1.
Sandbox escape in vm2 NodeVM before 3.12.1 allows unauthenticated remote attackers to execute arbitrary commands on the host, but only when the application has been configured to allow child_process via builtin:['*'] or an explicit allowlist entry. Exploitation requires the host application to run untrusted JavaScript inside a NodeVM instance and to have this misconfiguration; default configurations that do not allow child_process are not vulnerable. The vendor-supplied CVSS 4.0 vector rates this 10.0, while the independent CVSS 3.1 assessment reflects high attack complexity (AC:H) due to the required misconfiguration. No public exploit code or active exploitation has been identified at time of analysis.
Sandbox escape in vm2 through 3.12.0 lets unauthenticated remote attackers execute arbitrary code on the host when the embedding application exposes at least one non-strict (sloppy-mode) host function to the sandbox. By calling such a function with a nullish receiver (`fn()`, `fn.call()`, `Reflect.apply(fn, undefined, [])`, etc.), sandboxed script causes V8 to substitute the host realm’s global object for `this`, which vm2 then wraps and returns as a live proxy of the host global; the attacker can then reach `process` and run commands such as `process.getBuiltinModule('child_process').execSync`. Vendor-released patch: upgrade to 3.12.1; no public exploit identified at time of analysis, but the required pre-condition is common because ordinary JavaScript functions are non-strict by default, and vm2 is deprecated, so unmaintained deployments remain exposed-independent assessment rates this a top-tier priority.
Memory exhaustion denial of service in vm2 through 3.11.5 lets sandboxed JavaScript escalate beyond the operator-configured bufferAllocLimit by allocating host memory through ArrayBuffer, SharedArrayBuffer, and TypedArray constructors, which the cap never intercepts. Because the allocation is a single synchronous V8 call, vm2's timeout cannot interrupt it, and any deployment that runs untrusted code in a VM - the library's standard use case - is exposed without needing bufferAllocLimit to be enabled at all. Impact is availability-only (CVSS 4.0 8.7; independent assessment CVSS 3.1 AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H) and materializes as process OOM-kill, most quickly in memory-capped runtimes such as Docker, Kubernetes, or AWS Lambda; the GHSA advisory ships reproduction code but there is no indication of active exploitation (not listed in CISA KEV), and the issue is resolved in 3.11.6.
Sandboxed JavaScript executed inside vm2's NodeVM before 3.11.6 can step outside the isolation boundary to read host process identity and network topology and, worse, to hijack the host's DNS resolver process-wide. The exposure is gated by two conditions: the embedding application must run attacker-controlled code in NodeVM (the tool's core threat model) and must use the non-default wildcard whitelist builtin: ['*'], which fails to exclude the os and dns modules; the assessed vector is unauthenticated (CVSS PR:N), so once code reaches the sandbox no credentials or user interaction are needed, and a single dns.setServers() call persists for the life of the host process. No public exploit code or confirmed in-the-wild exploitation was identified at time of analysis, and the vendor-released patch is vm2 3.11.6. Real-world priority is driven less by raw severity than by whether a deployment both accepts untrusted code and enables the wildcard builtin list.
Sandboxed JavaScript in vm2 before 3.11.8 can bypass the allowAsync:false restriction by supplying an attacker-controlled thenable to Promise static methods, allowing asynchronous work to continue after VM.run() or NodeVM.run() returns and outside the configured timeout. This is a genuine but moderate-severity protection-mechanism failure (CWE-693) affecting applications that rely on the vm2 sandbox and its async restriction as a trust boundary for executing untrusted code; the CVSS vector indicates PR:L, reflecting the need to supply JavaScript code executed inside the sandbox. No public exploit identified at time of analysis.
Sandbox escape in vm2 through 3.11.6 lets untrusted JavaScript executing inside a NodeVM bypass the configured builtin-module denylist and reach the host filesystem via require('fs/promises') or require('node:fs/promises'), allowing host file creation and modification (confirmed through fsp.writeFile()) plus cp, mkdir, rename, rm, rmdir, truncate and read operations on the host. Exposure is configuration-dependent: only embedders that combine the builtin wildcard with negative entries (for example require: { builtin: ['*', '-fs', '-child_process'] }) are affected, while default configurations and allowlist-style restrictions are not, and no public exploit identified at time of analysis. The flaw is fixed in vm2 3.11.7. Note that the supplied CVSS 4.0 vector carries PR:L while the independent assessment's CVSS 3.1 vector carries PR:N, so authentication requirements are not unambiguously confirmed from available data; exploitation in practice requires only the pre-existing ability to submit sandboxed code.
Sandbox escape in the vm2 Node.js library through 3.11.6 lets untrusted code running inside a NodeVM instance reach the host's child_process builtin and execute operating-system commands whenever the embedding application configures a wildcard builtin require policy containing a node:-prefixed deny entry. The affected configuration (for example new NodeVM({ require: { builtin: ['*', '-node:child_process'] } })) fails to deny the canonical child_process module, so sandboxed code can obtain execSync and spawn via require('child_process') or require('node:child_process'), giving host command-execution capability to code that was supposed to be isolated (CVSS 4.0 base 9.4; assessed CVSS 3.1 AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H). Exploitation requires PR:L privileges in the sense that the attacker must already be able to run attacker-controlled JavaScript inside the sandbox, and it only works under that specific deny-list form; a correctly spelled '-child_process' entry, a non-wildcard allow-list, or not exposing child_process at all avoids the flaw. No public exploit code or confirmed active exploitation was identified at time of analysis.
Sandbox escape in vm2 3.10.1 through 3.11.6 on Node.js 26 lets code inside a default `new VM()` sandbox reach the host realm and recover the real host `process` object, granting full host Node.js capabilities such as loading host modules like fs, with high confidentiality, integrity, and availability impact on the process running the sandbox. The assessed vector is CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H (CVSS 4.0 base score 10.0), meaning unauthenticated remote attackers, and no NodeVM, require permission, or host-object injection is needed - the only hard precondition is that the host process runs Node.js 26. The issue bypasses the earlier JSPI fix for GHSA-6j2x-vhqr-qr7q and is fixed in 3.11.7; no public exploit identified at time of analysis.
Sandbox escape in the vm2 Node.js library (npm package patriksimek:vm2, all versions before 3.11.8) lets untrusted JavaScript executed inside a NodeVM instance reach the host process's __proto__ getter/setter through the sandboxed console._stdout and console._stderr objects, overwrite EventEmitter.prototype.emit, and trigger processes events so that attacker code runs with host process context. Per the vendor CVSS:4.0 vector the flaw is remotely reachable with PR:N and UI:N, so any application that feeds network-supplied JavaScript into a NodeVM gains no additional barrier beyond instantiating the sandbox; no authentication or user interaction is required once code reaches the evaluator. There is no KEV listing and no public exploit identified at time of analysis, but the assessed impact is a complete compromise of the hosting process (S:C/C:H/I:H/A:H), which is why this is treated as maximum severity within its threat model. Note that the AV:N rating reflects the common deployment where untrusted scripts arrive over the network - vm2 is not itself a standalone network service, and applications using it only for trusted code are unaffected.
A denial-of-service flaw in the vm2 Node.js sandbox library (versions 3.10.0 through 3.11.7) allows attacker-controlled JavaScript running inside a NodeVM sandbox to kill the host Node.js process by invoking a host-realm function that returns a rejected Promise and simply ignoring the return value. Because host-origin Promises crossing the bridge are not marked as handled, Node.js's default unhandled-rejection behavior terminates the process; the CVSS 4.0 score is 9.2, and the assessed vector (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:N/I:N/A:H) rates it unauthenticated and network-reachable but entirely gated on the target embedding vm2 to run untrusted code and exposing at least one host Promise-returning API (the advisory cites events.once() via the NodeVM events builtin). No public exploit code and no CISA KEV entry were identified at time of analysis, and this is an incomplete fix of GHSA-hw58-p9xv-2mjh that is resolved in vm2 3.11.8.
Prototype pollution in the vm2 Node.js sandbox (versions 3.11.0 through 3.11.7) lets JavaScript running inside a VM/NodeVM instance walk the prototype chain into host-realm intrinsics and mutate Uint8Array.prototype, %TypedArray%.prototype, and ArrayBuffer.prototype, so the pollution survives after VM.run() returns and is observed by host-created typed arrays. Because the vm2 usage model is to execute untrusted code, the CVSS 4.0 vector (AV:N/AC:L/PR:N/UI:N, VI:H/VA:H plus SI:H/SA:H) yields a 9.3 Critical sandbox-escape-class rating: unauthenticated remote attackers who can supply the sandboxed script can reach the host realm, though the impact is only realized if the host application subsequently creates or operates on host-side TypedArray/ArrayBuffer instances. No public exploit code was identified at time of analysis and the issue is not listed as confirmed actively exploited (CISA KEV), so risk is driven by upstream supply-chain exposure of applications embedding vm2 as an untrusted-code boundary. The vulnerability was reported by VulnCheck and is tracked under CWE-913.
vm2 versions 3.11.4 through 3.11.6 allow untrusted JavaScript running inside the sandbox to bypass cross-realm registered-symbol filtering and write Node.js internal stream symbols onto host WebStream objects, corrupting host-visible stream state - for example making stream.Readable.isDisturbed() return false for an already-consumed stream, which can defeat host logic that enforces one-shot body consumption or rejects errored streams. Exploitation is unauthenticated per the CVSS vector (PR:N) but requires a non-default setup: the embedder must expose both a host WebStream object and the host stream/web module to sandboxed code, and the host must run a Node.js release that exposes nodejs.stream.disturbed and nodejs.stream.errored on WebStream prototypes (validated on Node.js v25.8.0). Impact is integrity-only, with no host code execution, confidentiality, or availability loss in the reported proof; no public exploit code has been identified at time of analysis, and the flaw is fixed in vm2 3.11.7.
Sandbox escape in vm2 before 3.11.7 allows an attacker who can already execute JavaScript inside the vm2 sandbox to bypass the external package allowlist and cause unauthorized host packages to be loaded and executed in the host context. The flaw is an incorrect authorization check: vm2 uses non-exact substring matching when validating package names against the allowlist, so a colliding package name that contains an allowlisted substring is approved. Exploitation requires the host application to use vm2 for untrusted code and to rely on the external package allowlist as a trust boundary; the CVSS vector indicates PR:L, meaning low privileges are required, and no public exploit or CISA KEV confirmed active exploitation was identified at time of analysis.
Sandbox escape in the vm2 Node.js sandboxing library before 3.11.7 lets an attacker who supplies a malicious script file to the vm2 command-line tool execute arbitrary code in the host Node.js process, gaining access to host modules such as fs and child_process. The vulnerable entry point is the CLI utility specifically, not the library's programmatic VM/NodeVM API: an attacker-crafted script uses require(__filename) to re-execute itself in the host realm and slip past the sandbox membrane. Exploitation is local rather than network-facing (CVSS 4.0 AV:L/UI:P, PR:N), requiring a victim or automated job to invoke the vm2 CLI against the attacker-controlled file; the vendor rating is 9.3 (critical), but the local vector and required user interaction make real-world exposure materially narrower than the network-facing vm2 escapes, and there is no public exploit identified at time of analysis.
Sandbox escape in vm2 3.9.6 through 3.11.6 lets attacker-supplied JavaScript running inside a NodeVM break out and execute arbitrary code in the host Node.js process when three conditions line up: the host runs Node.js 24 or newer, the embedder has explicitly allowlisted the node:test builtin, and the sandboxed code is under attacker control. The bypass exists because vm2's family-based DANGEROUS_BUILTINS check does not recognise Node.js 24's scheme-only 'node:test' key, so the module is placed in the generic host-passthrough loader, and a single 'node:' prefix strip in requireImpl() means require('node:node:test') resolves to that stored key; forwarded node:test.run() calls reach the host implementation, which spawns a separate Node process and honours attacker-supplied execArgv values such as --eval=<JavaScript>. Vendor severity is 9.4 (CVSS 4.0) and our independent assessment scores it CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H, a genuine full sandbox escape to host code execution whose real-world reachability is constrained by the hard Node.js 24+ and non-default node:test allowlist prerequisites; no public exploit identified at time of analysis. Fixed in vm2 3.11.7.
Sandbox escape in vm2 before 3.11.7 lets attacker-supplied JavaScript running inside the sandbox read and write Node.js Buffer memory that belongs to the host realm, exposing sensitive host data drawn from Buffer.from, Buffer.concat and similar allocations while also enabling memory-pressure/availability abuse. The only precondition is that the host application executes untrusted code through vm2 - the library's core use case for plugin engines, eval services and code runners - so no special toggle is required; a remote attacker is unauthenticated per the CVSS vector (PR:N) but there is no over-the-network attack path against vm2 in isolation, and applications that only run trusted code or have already migrated to isolated-vm are unaffected. The vendor assigns CVSS 4.0 10.0 (VC:H/VI:H/SC:H/SI:H), while our independent assessment of the same issue is CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:L/A:L - we agree on the confidentiality and sandbox-boundary (scope-change) severity but rate integrity impact lower; no public exploit identified at time of analysis and no CISA KEV entry, though the deployment pattern makes weaponizable preconditions trivial once a sandbox is reachable. Fixed in 3.11.7.
Sandbox escape leading to remote code execution affects the vm2 Node.js sandbox library before version 3.11.7 when the embedding application enables require.external without an explicit require.root that excludes node_modules. Under that configuration, attacker-supplied JavaScript running inside the sandbox can require vm2's own package, construct an unrestricted NodeVM instance, and then execute arbitrary host OS commands through child_process, yielding a complete escape from the sandbox to the underlying operating system. Exploitation requires two operator-chosen, non-default preconditions (running untrusted code in vm2 AND the permissive require configuration), so deployments that leave require.external disabled or pin require.root away from node_modules are not exposed; no public exploit code was identified at time of analysis, and the vendor-released fix is version 3.11.7.
Sandbox escape in the vm2 npm library versions 3.10.2 through 3.11.6, when running on Node.js 26, allows attacker-supplied JavaScript to break out of the sandbox and reach the host Function constructor and process object, resulting in arbitrary code execution. The escape is unauthenticated and requires no special vm2 configuration - no require.external, builtin allowlists, or unsafe options - but it is gated on the Node.js 26 / V8 14.6 runtime, so the same vm2 versions on other Node.js major versions are not affected by this finding. No public exploit code and no confirmed active exploitation were identified at time of analysis; the practical prerequisite is that a deployment accepts and executes untrusted code inside vm2, which is the library's core threat model.
Denial of service in vm2 through 3.11.6 lets sandboxed JavaScript escape the VM({ timeout }) accounting and block the host event loop indefinitely. Because FinalizationRegistry and WeakRef are exposed to the sandbox unmodified (they are not among the hardened globals in lib/setup-sandbox.js) and the timeout only wraps the single _runScript() call via doWithTimeout() in lib/vm.js, sandboxed code can register a FinalizationRegistry cleanup callback, drop the last strong reference to the target object, and return from vm.run() well within the configured timeout; when V8 later reclaims the object it invokes the sandboxed callback with no timeout in effect, so a busy loop there hangs the host process for an unbounded period. Exploitation requires a host application that executes attacker-controlled JavaScript inside vm2 and relies on VM({timeout}) as its resource-exhaustion control - vm2's intended use case. Impact is availability only (no sandbox escape, code execution, or data disclosure), and no public exploit identified at time of analysis; the main practical limiter is that GC timing is non-deterministic and only loosely influenced by the attacker via memory pressure or --expose-gc.
Sandbox escape in vm2 3.11.3 through 3.11.6 lets JavaScript executing inside a NodeVM instance reach the host tls module and call tls.setDefaultCACertificates(), overwriting the process-wide default certificate authority store so that subsequent host HTTPS clients will accept attacker-supplied certificates. The flaw is config-gated rather than a default-configuration remote exploit: the host application must both run attacker-controlled JavaScript inside vm2 and expli(他)citly add the 'tls' and 'url' modules to the sandbox builtin allowlist, which is not vm2's default builtin set, and meaningful data compromise additionally requires the attacker to hold a network man-in-the-middle position to present the newly trusted forged certificate. Consistent with those prerequisites, our assessment scores this as CVSS 3.1 AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:L (unauthenticated from the network, but high attack complexity and scope-changing sandbox-integrity impact) rather than the unmodified 10.0 of the supplied CVSS 4.0 vector; no public exploit code and no confirmed active exploitation were identified at time of analysis.
Credential disclosure and HTTPS session hijacking in vm2 3.11.3 through 3.11.6 allow sandboxed JavaScript to read host Authorization headers, private destination host/port information, and subsequent plaintext response bodies when a NodeVM is explicitly configured to allow require('https') and the host process concurrently issues outbound HTTPS requests. The vendor rates this CVSS 4.0 10.0, but our independent assessment scores it CVSS 3.1 AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:L/A:N; exploitation requires the non-default require('https') configuration plus opportunistic timing when pooled host connections emit the 'free' event. There is no public exploit identified at time of analysis, and no CISA KEV confirmation was provided in the intelligence.
Sandbox escape and arbitrary native code execution in vm2 3.11.3 through 3.11.6 occurs when a NodeVM sandbox is configured to allow the host crypto builtin: sandboxed JavaScript can reach crypto.setEngine() and hand it a filesystem path pointing at an attacker-supplied shared library (for example one shipped inside an untrusted plugin package already unpacked to disk), which OpenSSL passes to the operating system's dynamic loader and whose constructor then executes in the host process. Exploitation needs the crypto builtin alone - fs, process, module, child_process, worker_threads, vm and inspector access are all unnecessary - and there is no public exploit code or confirmed active exploitation (no CISA KEV listing) at time of analysis, though the reporter-assigned score of 9.4 reflects the severity if those prerequisites are met. Real-world urgency is gated by deployment-specific factors: the crypto builtin must be explicitly exposed to the sandbox and the host must already contain an attacker-writable native library, so a patched release or a tightened builtin allow-list fully removes the attack surface.
Native code execution outside the sandbox affects vm2 versions 3.11.3 through 3.11.6 when the host node:sqlite builtin is exposed to a NodeVM sandbox - either explicitly or through the wildcard builtin: ['*'] - which is not a default configuration. Sandboxed plugin code can create an in-memory DatabaseSync with extension loading turned on, resolve an attacker-supplied native library via a __dirname-derived path, and call loadExtension(), causing SQLite to load that library into the Node.js host process and execute its native entry point with host privileges; the vm.readonly() wrapper prevents property assignment but leaves host-authority callables reachable, and a 'node:node:sqlite' double-prefix quirk in the resolver/prefix-stripping logic lets the sandbox reach the configured builtin. There is no public exploit identified at time of analysis and no confirmed active exploitation (CISA KEV) - the vendor released vm2 3.11.7 to fix it. Real-world priority is strongly gated by configuration: exploitation requires all of permitting node:sqlite in the sandbox, enabling SQLite extension loading, and having an attacker-controlled .so/.dll on disk within the plugin package.
Sandbox escape leading to remote code execution in vm2 3.11.6 lets untrusted code inside the sandbox reach a live proxy to a host-realm object and run commands with the host process privileges, for example through e.detail.mainModule.require('child_process').execSync(...). The flaw is an incomplete fix for GHSA-m283-3h24-438v: registering a rejection handler via Function.prototype.call or .apply indirection (p.then.call(p, undefined, cb)) bypasses the identity check at lib/bridge.js:1624, so the raw host Error and its non-primitive own properties are handed to sandbox code. Exploitation is conditional: the embedder must bridge an async host Promise into the sandbox and that Promise must reject with an Error carrying a non-primitive own property that references a host object (for example err.detail = process); direct p.then(undefined, cb), .bind and Reflect.apply forms are correctly sanitised. Upgrade to vm2 3.11.7 closes the bypass; no public exploit identified at time of analysis.
Sandbox escape and remote code execution in vm2 versions 3.11.4 through 3.11.6 allow JavaScript executed inside a NodeVM to break out and run arbitrary commands with the privileges of the host Node.js process. The flaw is reachable only in a specific, non-default configuration where the NodeVM is created with a truthy `nesting` value and an array-shaped `require` option (for example `new NodeVM({nesting: true, require: []})`); in that case the array satisfies a guard intended to reject nesting without an explicit require configuration, and the resulting resolver falls back to a nesting override that permits the sandboxed code to require the host `vm2` module and construct an inner NodeVM with an attacker-chosen builtin allowlist such as `child_process`. Exploitation requires no authentication or user interaction (CVSS 4.0 vector reports PR:N/UI:N) beyond the ability to supply code the sandbox runs, which is vm2's intended threat model; there is no public exploit code or CISA KEV confirmation of active exploitation at time of analysis, but the impact is complete confidentiality, integrity, and availability loss on the host, and the vendor CVSS 4.0 score of 9.5 is consistent with that assessed impact.
Sandbox escape in vm2 before 3.11.8 allows unauthenticated remote attackers to achieve full remote code execution and host process information disclosure by crafting a host-wrapped AggregateError that is revisited within a single exception-handler traversal, bypassing handleException's cycle detection and exposing unsanitized host proxies in the errors array. The flaw is an incomplete fix for Error.cause sanitization, and exploitation requires the host application to execute attacker-controlled JavaScript inside a vulnerable vm2 instance, which is vm2's normal use case, though the malformed-error and traversal condition is non-trivial (CVSS AC:H/AT:P). No public exploit identified at time of analysis; environments that do not run untrusted code in vm2, or that have migrated off the deprecated vm2, are not exposed.
Sandbox escape in vm2 (patriksimek/vm2) versions prior to 3.11.3 enables remote code execution on the host Node.js process by abusing async generator `yield*` semantics to smuggle a host-realm exception into sandbox code, where the attacker pivots through `.constructor.constructor` to reach `process` and `child_process.execSync`. The flaw is exploitable by any attacker who can run JavaScript inside the sandbox, has publicly available exploit code, and carries SSVC technical impact 'total' with automatable=yes, though EPSS remains low at 0.05% (17th percentile) and the CVE is not listed in CISA KEV.
Full sandbox escape with arbitrary code execution allows remote attackers to break out of vm2's Node.js sandbox environment (version 3.10.4) and execute commands on the host system. Attacker-controlled code running inside VM.run() can obtain the host process object and execute arbitrary host commands without any cooperation from the host application. EPSS data not available, but this represents complete failure of the sandbox security boundary. Patch released in version 3.10.5 addresses eleven distinct escape vectors including Function constructor leakage, proxy unwrapping, util.inspect exposure, and WebAssembly exception handling.
Sandbox escape leading to remote code execution in the vm2 Node.js sandbox library affects all versions prior to 3.11.0, where the JavaScript SuppressedError mechanism (combined with DisposableStack disposal) lets untrusted code running inside the sandbox reach a host constructor and execute arbitrary commands on the underlying server. Any application that relies on vm2 to safely run attacker-controlled or untrusted JavaScript is fully compromised, with a working proof-of-concept published in the GHSA advisory. There is publicly available exploit code but no confirmed active exploitation; the SSVC framework rates it POC, automatable, with total technical impact, while EPSS remains low at 0.06%.
Remote code execution in vm2 (Node.js sandbox library) versions prior to 3.11.0 allows unauthenticated attackers to escape the sandbox environment via the inspect function and execute arbitrary system commands. The vulnerability exploits handler leakage through util.inspect's showProxy option to reconstruct host-realm objects and break isolation guarantees. CRITICAL: This is a complete sandbox bypass affecting all deployments using vm2 for untrusted code execution. Vendor-released patch available in version 3.11.0 with multiple commits addressing eight distinct exploitation primitives discovered during iterative disclosure.
Sandbox escape in vm2 for Node.js allows remote unauthenticated attackers to execute arbitrary commands on the host system. The vulnerability represents an insufficient fix for CVE-2023-37466, enabling attackers to circumvent sandbox protections through multiple attack vectors including Function constructor extraction, proxy unwrapping, property descriptor manipulation, and WebAssembly JSTag exploitation. CVSS 9.8 (Critical) with EPSS data unavailable, but the existence of a detailed security advisory and comprehensive patch from GitHub indicates active vendor awareness and rapid response. Patched in version 3.10.5 with eleven distinct fixes addressing various bypass techniques.
Information disclosure and cross-boundary host memory corruption in vm2 before 3.12.2 let untrusted guest JavaScript read and modify bytes outside the sandbox whenever the embedding application explicitly allowlists Node's zlib builtin via require: { builtin: ['zlib'] }. vm2 fails to apply its Buffer backing-store ownership invariant (byteOffset === 0 && buffer.byteLength === length) to Buffers returned from host builtin modules, so zlib.deflateSync can hand back a pooled buffer whose .buffer getter exposes Node's entire 64 KiB shared small-buffer pool; a guest then builds a full-width view with Buffer.from(result.buffer, 0, result.buffer.byteLength) to disclose secrets (session tokens, decrypted material, DB rows) and corrupt unrelated host buffers sharing that pool. This is not reachable in a default vm2 deployment - it requires a non-default zlib allowlist, attacker-controlled script execution, and host secrets co-resident in the pool at exploitation time - and no public exploit code was identified at time of analysis; the vendor rates it CVSS 4.0 6.9 (Medium) with a vendor-released patch in 3.12.2.
Sandbox escape in vm2 through 3.12.0 lets untrusted guest code cross the NodeVM isolation boundary and change process-wide state by calling crypto.setFips(), which toggles the FIPS mode of the entire host Node.js process (observed as crypto.getFips() flipping from 0 to 1 in the reporter's test). The vulnerability is only reachable when the embedding application runs vm2 as a NodeVM with the non-default, opt-in configuration require.builtin: ['crypto']; authentication and user interaction are not required in that scenario, and the practical impact is limited to low-integrity and low-availability effects rather than arbitrary host code execution or data disclosure. No public exploit identified at time of analysis; the issue is fixed in vm2 3.12.1, available from the vendor (GHSA-x3v6-43hc-82mc).
Untrusted JavaScript running inside a vm2 sandbox before version 3.11.2 can reach the host-side internal state object via globalThis['VM2_INTERNAL_STATE_DO_NOT_USE_OR_PROGRAM_WILL_FAIL'], disclosing sandbox internals that were supposed to be invisible to guest code in the npm package vm2. The issue is a re-bypass of the earlier advisory GHSA-wp5r-2gw5-m7q7, and a short working proof-of-concept is published in the vendor advisory GHSA-2cm2-m3w5-gp2f, so publicly available exploit code exists; no CISA KEV listing appears in the supplied intelligence and no EPSS value was provided. The CVSS 4.0 base score is 6.9 with a confidentiality-only impact (VC:L, VI:N, VA:N, SC:N, PR:N, UI:N), consistent with the independent assessment that this is a genuine but low-severity information disclosure with no demonstrated code execution, integrity, or availability effect; the unauthenticated PR:N rating reflects the vector, while in practice the attacker must already be able to execute code inside the vm2 trust boundary (an application that embeds vm2 and runs attacker-controlled scripts).
Sandboxed JavaScript running in the npm package vm2 3.11.3 and earlier can install an accessor on Array.prototype so that the bridge's defaultSandboxPrepareStackTrace routine writes each stack-trace line through that attacker-controlled setter, allowing in-sandbox code to observe and intercept the formatted stack-trace strings the host builds. The impact is confined to a low-bandwidth information side channel and a violation of vm2's documented bridge-container defense invariant; there is no sandbox escape and no code execution, which is why the vendor rates the issue Low, consistent with a published CVSS 4.0 base score of 2.1 and our assessed CVSS:3.1/AV:L/AC:H/PR:N/UI:N/S:C/C:L/I:N/A:N. The practical precondition is that the host application runs attacker-controlled JavaScript inside a vulnerable vm2 sandbox and that the sandboxed code arrange a prototype setter before error.stack (or any path triggering Error.prepareStackTrace) is read; no public exploit code or active exploitation has been identified at time of analysis, and the assessed vector carries PR:N, meaning no additional privileges beyond sandbox code execution are required.
Sandbox escape and read-only bypass in vm2 3.9.6 through 3.11.6 lets untrusted JavaScript running inside a NodeVM defeat the vm.freeze() and vm.readonly() protections and mutate host object properties that the embedder explicitly marked immutable. An attacker uses Object.getOwnPropertyDescriptor() or __lookupSetter__() to recover host-realm setters from accessor properties on frozen objects and invoke them directly, circumventing the Proxy-based restrictions. The CVSS 4.0 vector (PR:N, AC:H, AT:P, VI:L/SI:L, no C/I/A beyond low integrity) confirms unauthenticated access but high attack complexity and an integrity-only ceiling with no code execution; two prerequisites must hold (untrusted code executed in vm2, and reliance on vm.freeze()/vm.readonly() to protect reachable host objects). No public exploit identified at time of analysis, there is no CISA KEV listing, and vm2 is deprecated, which further narrows realistic exposure to legacy deployments using versions 3.9.6 to 3.11.6.
Module allowlist bypass in vm2 before 3.11.7 lets JavaScript that is already executing inside the sandbox load packages the host intended to forbid, by performing a relative require from an allowlisted package to a non-allowlisted package whose resolved path only shares a leading string prefix with an allowlisted module. Exploitation is not remote or automatic: it requires the host application to deliberately run untrusted code in vm2, an enforced module allowlist combined with disabled transitive loading, and a prefix-collision package layout, which is why our independent assessment scores it as a low-severity, high-complexity weakness (CVSS 3.1 AV:N/AC:H/PR:L/UI:N/S:U/C:L/I:L/A:N, attack requirements present) rather than a sandbox escape; there is no public exploit identified at time of analysis and no confirmed active exploitation (no CISA KEV listing).
Absolute host filesystem path disclosure in vm2 3.11.0 through 3.11.6 allows attacker-supplied JavaScript running inside a vm2 sandbox to force the host-realm source transformer to throw a SyntaxError (for example via eval with malformed source) and then read the resulting error's .stack property, which the bridge forwards to the host-realm formatter. Default new VM() and new NodeVM() configurations are affected with no special options, and the leak persists even when string eval is disabled, because the host-side transformer throws before eval is handled. Only information disclosure results - absolute paths from vm2, Node.js internals, and the embedding application's source tree plus host function names - with no write, no code execution, and no public exploit identified at time of analysis; the CVSS 4.0 score of 6.9 reflects the scope change and low confidentiality impact rather than a high-severity outcome.
Information disclosure in vm2 through version 3.11.7 allows sandboxed Node.js code to read the host process's call stack metadata: NodeVM exposes the host util module as an unfiltered shallow copy and also exposes the deprecated sys alias, and on Node.js 22.9 or later this hands sandbox code util.getCallSites(), which returns absolute file paths, function names, and line numbers for vm2 bridge internals and the embedding application's entrypoint. Remote attackers are unauthenticated (CVSS PR:N), but exploitation requires the host application to actually execute attacker-controlled JavaScript inside NodeVM and to be running Node.js >= 22.9; the leak is read-only and grants no code execution or write access. Vendor-released patch: vm2 3.11.8. No confirmed active exploitation (no CISA KEV listing) and no public exploit code identified at time of analysis.
Denial of service in vm2 sandboxes before 3.12.2 allows an untrusted script running via VM.run to terminate the host Node.js process. The BaseHandler construct trap returns Reflect.construct's result without calling markHostPromiseHandled() the way the adjacent apply trap does, so if an embedder exposes a constructable host function whose constructor returns a resident rejected Promise, invoking it with `new` and discarding the result lets the rejection cross the sandbox bridge unhandled; under Node's default strict unhandled-rejection policy this is promoted to a process-terminating uncaught exception. The bug is unauthenticated in the sense that the attacker only needs to submit script code (PR:N/UI:N), but exploitation is conditional: it requires a specific embedder integration exposing such a constructable Promise-returning host constructor, which is the AT:P precondition and is not vm2 default behavior; no public exploit code was identified at time of analysis and the issue is not in CISA KEV.
Sandbox escape leading to arbitrary host code execution in vm2 (the npm sandbox library, CPE cpe:2.3:a:patriksimek:vm2) affects all versions before 3.12.2 when NodeVM is configured with a custom `require.external` resolver and `context: 'host'`. Because the resolver records the allowed module directory as an unanchored prefix pattern, untrusted guest code can require an allowlisted package (e.g. `foo`) and then require a non-allowlisted sibling sharing that prefix (e.g. `node_modules/foo2/index.js`), whose top-level code is loaded via `hostRequire` in the host process before `vm.readonly` wrapping, yielding code execution outside the sandbox. Exploitation requires the non-default host-passthrough external-resolver deployment plus a prefix-sharing sibling package, but needs no authentication or user interaction (CVSS:4.0 9.5, AT:P/PR:N/UI:N; assessed CVSS:3.1 AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:H); no public exploit code was identified at time of analysis and the flaw is not in CISA KEV, though the vendor has published patched commits and version 3.12.2.
Sandbox escape in vm2 3.12.0 and earlier allows unauthenticated remote attackers who can supply JavaScript to an application embedding vm2's VM or NodeVM to break out of the sandbox and execute arbitrary code on the host, provided the embedder exposes at least one host API returning a host-realm (native) Promise whose rejection value is host-pivotable - the advisory cites a host process object as the example. The flaw is an incomplete rejection-sanitization failure in lib/bridge.js: the sandbox-side Symbol.species and .then neutralization is installed only on the sandbox intrinsic Promise.prototype, so it never applies to host Promises, letting sandboxed code overwrite p.constructor[Symbol.species] and call p.then() without an onRejected handler, after which V8's internal Thrower re-throws the raw host rejection value into an attacker-controlled resolve/reject closure, bypassing handleException and hostPromiseSanitizeReject and yielding an unsanitized, fully functional bridge proxy of the host object. No public exploit identified at time of analysis, but the CVSS 4.0 base score is 10.0 and the issue is fixed in 3.12.1.
Sandbox escape in vm2 NodeVM before 3.12.1 allows unauthenticated remote attackers to execute arbitrary commands on the host, but only when the application has been configured to allow child_process via builtin:['*'] or an explicit allowlist entry. Exploitation requires the host application to run untrusted JavaScript inside a NodeVM instance and to have this misconfiguration; default configurations that do not allow child_process are not vulnerable. The vendor-supplied CVSS 4.0 vector rates this 10.0, while the independent CVSS 3.1 assessment reflects high attack complexity (AC:H) due to the required misconfiguration. No public exploit code or active exploitation has been identified at time of analysis.
Sandbox escape in vm2 through 3.12.0 lets unauthenticated remote attackers execute arbitrary code on the host when the embedding application exposes at least one non-strict (sloppy-mode) host function to the sandbox. By calling such a function with a nullish receiver (`fn()`, `fn.call()`, `Reflect.apply(fn, undefined, [])`, etc.), sandboxed script causes V8 to substitute the host realm’s global object for `this`, which vm2 then wraps and returns as a live proxy of the host global; the attacker can then reach `process` and run commands such as `process.getBuiltinModule('child_process').execSync`. Vendor-released patch: upgrade to 3.12.1; no public exploit identified at time of analysis, but the required pre-condition is common because ordinary JavaScript functions are non-strict by default, and vm2 is deprecated, so unmaintained deployments remain exposed-independent assessment rates this a top-tier priority.
Memory exhaustion denial of service in vm2 through 3.11.5 lets sandboxed JavaScript escalate beyond the operator-configured bufferAllocLimit by allocating host memory through ArrayBuffer, SharedArrayBuffer, and TypedArray constructors, which the cap never intercepts. Because the allocation is a single synchronous V8 call, vm2's timeout cannot interrupt it, and any deployment that runs untrusted code in a VM - the library's standard use case - is exposed without needing bufferAllocLimit to be enabled at all. Impact is availability-only (CVSS 4.0 8.7; independent assessment CVSS 3.1 AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H) and materializes as process OOM-kill, most quickly in memory-capped runtimes such as Docker, Kubernetes, or AWS Lambda; the GHSA advisory ships reproduction code but there is no indication of active exploitation (not listed in CISA KEV), and the issue is resolved in 3.11.6.
Sandboxed JavaScript executed inside vm2's NodeVM before 3.11.6 can step outside the isolation boundary to read host process identity and network topology and, worse, to hijack the host's DNS resolver process-wide. The exposure is gated by two conditions: the embedding application must run attacker-controlled code in NodeVM (the tool's core threat model) and must use the non-default wildcard whitelist builtin: ['*'], which fails to exclude the os and dns modules; the assessed vector is unauthenticated (CVSS PR:N), so once code reaches the sandbox no credentials or user interaction are needed, and a single dns.setServers() call persists for the life of the host process. No public exploit code or confirmed in-the-wild exploitation was identified at time of analysis, and the vendor-released patch is vm2 3.11.6. Real-world priority is driven less by raw severity than by whether a deployment both accepts untrusted code and enables the wildcard builtin list.
Sandboxed JavaScript in vm2 before 3.11.8 can bypass the allowAsync:false restriction by supplying an attacker-controlled thenable to Promise static methods, allowing asynchronous work to continue after VM.run() or NodeVM.run() returns and outside the configured timeout. This is a genuine but moderate-severity protection-mechanism failure (CWE-693) affecting applications that rely on the vm2 sandbox and its async restriction as a trust boundary for executing untrusted code; the CVSS vector indicates PR:L, reflecting the need to supply JavaScript code executed inside the sandbox. No public exploit identified at time of analysis.
Sandbox escape in vm2 through 3.11.6 lets untrusted JavaScript executing inside a NodeVM bypass the configured builtin-module denylist and reach the host filesystem via require('fs/promises') or require('node:fs/promises'), allowing host file creation and modification (confirmed through fsp.writeFile()) plus cp, mkdir, rename, rm, rmdir, truncate and read operations on the host. Exposure is configuration-dependent: only embedders that combine the builtin wildcard with negative entries (for example require: { builtin: ['*', '-fs', '-child_process'] }) are affected, while default configurations and allowlist-style restrictions are not, and no public exploit identified at time of analysis. The flaw is fixed in vm2 3.11.7. Note that the supplied CVSS 4.0 vector carries PR:L while the independent assessment's CVSS 3.1 vector carries PR:N, so authentication requirements are not unambiguously confirmed from available data; exploitation in practice requires only the pre-existing ability to submit sandboxed code.
Sandbox escape in the vm2 Node.js library through 3.11.6 lets untrusted code running inside a NodeVM instance reach the host's child_process builtin and execute operating-system commands whenever the embedding application configures a wildcard builtin require policy containing a node:-prefixed deny entry. The affected configuration (for example new NodeVM({ require: { builtin: ['*', '-node:child_process'] } })) fails to deny the canonical child_process module, so sandboxed code can obtain execSync and spawn via require('child_process') or require('node:child_process'), giving host command-execution capability to code that was supposed to be isolated (CVSS 4.0 base 9.4; assessed CVSS 3.1 AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H). Exploitation requires PR:L privileges in the sense that the attacker must already be able to run attacker-controlled JavaScript inside the sandbox, and it only works under that specific deny-list form; a correctly spelled '-child_process' entry, a non-wildcard allow-list, or not exposing child_process at all avoids the flaw. No public exploit code or confirmed active exploitation was identified at time of analysis.
Sandbox escape in vm2 3.10.1 through 3.11.6 on Node.js 26 lets code inside a default `new VM()` sandbox reach the host realm and recover the real host `process` object, granting full host Node.js capabilities such as loading host modules like fs, with high confidentiality, integrity, and availability impact on the process running the sandbox. The assessed vector is CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H (CVSS 4.0 base score 10.0), meaning unauthenticated remote attackers, and no NodeVM, require permission, or host-object injection is needed - the only hard precondition is that the host process runs Node.js 26. The issue bypasses the earlier JSPI fix for GHSA-6j2x-vhqr-qr7q and is fixed in 3.11.7; no public exploit identified at time of analysis.
Sandbox escape in the vm2 Node.js library (npm package patriksimek:vm2, all versions before 3.11.8) lets untrusted JavaScript executed inside a NodeVM instance reach the host process's __proto__ getter/setter through the sandboxed console._stdout and console._stderr objects, overwrite EventEmitter.prototype.emit, and trigger processes events so that attacker code runs with host process context. Per the vendor CVSS:4.0 vector the flaw is remotely reachable with PR:N and UI:N, so any application that feeds network-supplied JavaScript into a NodeVM gains no additional barrier beyond instantiating the sandbox; no authentication or user interaction is required once code reaches the evaluator. There is no KEV listing and no public exploit identified at time of analysis, but the assessed impact is a complete compromise of the hosting process (S:C/C:H/I:H/A:H), which is why this is treated as maximum severity within its threat model. Note that the AV:N rating reflects the common deployment where untrusted scripts arrive over the network - vm2 is not itself a standalone network service, and applications using it only for trusted code are unaffected.
A denial-of-service flaw in the vm2 Node.js sandbox library (versions 3.10.0 through 3.11.7) allows attacker-controlled JavaScript running inside a NodeVM sandbox to kill the host Node.js process by invoking a host-realm function that returns a rejected Promise and simply ignoring the return value. Because host-origin Promises crossing the bridge are not marked as handled, Node.js's default unhandled-rejection behavior terminates the process; the CVSS 4.0 score is 9.2, and the assessed vector (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:N/I:N/A:H) rates it unauthenticated and network-reachable but entirely gated on the target embedding vm2 to run untrusted code and exposing at least one host Promise-returning API (the advisory cites events.once() via the NodeVM events builtin). No public exploit code and no CISA KEV entry were identified at time of analysis, and this is an incomplete fix of GHSA-hw58-p9xv-2mjh that is resolved in vm2 3.11.8.
Prototype pollution in the vm2 Node.js sandbox (versions 3.11.0 through 3.11.7) lets JavaScript running inside a VM/NodeVM instance walk the prototype chain into host-realm intrinsics and mutate Uint8Array.prototype, %TypedArray%.prototype, and ArrayBuffer.prototype, so the pollution survives after VM.run() returns and is observed by host-created typed arrays. Because the vm2 usage model is to execute untrusted code, the CVSS 4.0 vector (AV:N/AC:L/PR:N/UI:N, VI:H/VA:H plus SI:H/SA:H) yields a 9.3 Critical sandbox-escape-class rating: unauthenticated remote attackers who can supply the sandboxed script can reach the host realm, though the impact is only realized if the host application subsequently creates or operates on host-side TypedArray/ArrayBuffer instances. No public exploit code was identified at time of analysis and the issue is not listed as confirmed actively exploited (CISA KEV), so risk is driven by upstream supply-chain exposure of applications embedding vm2 as an untrusted-code boundary. The vulnerability was reported by VulnCheck and is tracked under CWE-913.
vm2 versions 3.11.4 through 3.11.6 allow untrusted JavaScript running inside the sandbox to bypass cross-realm registered-symbol filtering and write Node.js internal stream symbols onto host WebStream objects, corrupting host-visible stream state - for example making stream.Readable.isDisturbed() return false for an already-consumed stream, which can defeat host logic that enforces one-shot body consumption or rejects errored streams. Exploitation is unauthenticated per the CVSS vector (PR:N) but requires a non-default setup: the embedder must expose both a host WebStream object and the host stream/web module to sandboxed code, and the host must run a Node.js release that exposes nodejs.stream.disturbed and nodejs.stream.errored on WebStream prototypes (validated on Node.js v25.8.0). Impact is integrity-only, with no host code execution, confidentiality, or availability loss in the reported proof; no public exploit code has been identified at time of analysis, and the flaw is fixed in vm2 3.11.7.
Sandbox escape in vm2 before 3.11.7 allows an attacker who can already execute JavaScript inside the vm2 sandbox to bypass the external package allowlist and cause unauthorized host packages to be loaded and executed in the host context. The flaw is an incorrect authorization check: vm2 uses non-exact substring matching when validating package names against the allowlist, so a colliding package name that contains an allowlisted substring is approved. Exploitation requires the host application to use vm2 for untrusted code and to rely on the external package allowlist as a trust boundary; the CVSS vector indicates PR:L, meaning low privileges are required, and no public exploit or CISA KEV confirmed active exploitation was identified at time of analysis.
Sandbox escape in the vm2 Node.js sandboxing library before 3.11.7 lets an attacker who supplies a malicious script file to the vm2 command-line tool execute arbitrary code in the host Node.js process, gaining access to host modules such as fs and child_process. The vulnerable entry point is the CLI utility specifically, not the library's programmatic VM/NodeVM API: an attacker-crafted script uses require(__filename) to re-execute itself in the host realm and slip past the sandbox membrane. Exploitation is local rather than network-facing (CVSS 4.0 AV:L/UI:P, PR:N), requiring a victim or automated job to invoke the vm2 CLI against the attacker-controlled file; the vendor rating is 9.3 (critical), but the local vector and required user interaction make real-world exposure materially narrower than the network-facing vm2 escapes, and there is no public exploit identified at time of analysis.
Sandbox escape in vm2 3.9.6 through 3.11.6 lets attacker-supplied JavaScript running inside a NodeVM break out and execute arbitrary code in the host Node.js process when three conditions line up: the host runs Node.js 24 or newer, the embedder has explicitly allowlisted the node:test builtin, and the sandboxed code is under attacker control. The bypass exists because vm2's family-based DANGEROUS_BUILTINS check does not recognise Node.js 24's scheme-only 'node:test' key, so the module is placed in the generic host-passthrough loader, and a single 'node:' prefix strip in requireImpl() means require('node:node:test') resolves to that stored key; forwarded node:test.run() calls reach the host implementation, which spawns a separate Node process and honours attacker-supplied execArgv values such as --eval=<JavaScript>. Vendor severity is 9.4 (CVSS 4.0) and our independent assessment scores it CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H, a genuine full sandbox escape to host code execution whose real-world reachability is constrained by the hard Node.js 24+ and non-default node:test allowlist prerequisites; no public exploit identified at time of analysis. Fixed in vm2 3.11.7.
Sandbox escape in vm2 before 3.11.7 lets attacker-supplied JavaScript running inside the sandbox read and write Node.js Buffer memory that belongs to the host realm, exposing sensitive host data drawn from Buffer.from, Buffer.concat and similar allocations while also enabling memory-pressure/availability abuse. The only precondition is that the host application executes untrusted code through vm2 - the library's core use case for plugin engines, eval services and code runners - so no special toggle is required; a remote attacker is unauthenticated per the CVSS vector (PR:N) but there is no over-the-network attack path against vm2 in isolation, and applications that only run trusted code or have already migrated to isolated-vm are unaffected. The vendor assigns CVSS 4.0 10.0 (VC:H/VI:H/SC:H/SI:H), while our independent assessment of the same issue is CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:L/A:L - we agree on the confidentiality and sandbox-boundary (scope-change) severity but rate integrity impact lower; no public exploit identified at time of analysis and no CISA KEV entry, though the deployment pattern makes weaponizable preconditions trivial once a sandbox is reachable. Fixed in 3.11.7.
Sandbox escape leading to remote code execution affects the vm2 Node.js sandbox library before version 3.11.7 when the embedding application enables require.external without an explicit require.root that excludes node_modules. Under that configuration, attacker-supplied JavaScript running inside the sandbox can require vm2's own package, construct an unrestricted NodeVM instance, and then execute arbitrary host OS commands through child_process, yielding a complete escape from the sandbox to the underlying operating system. Exploitation requires two operator-chosen, non-default preconditions (running untrusted code in vm2 AND the permissive require configuration), so deployments that leave require.external disabled or pin require.root away from node_modules are not exposed; no public exploit code was identified at time of analysis, and the vendor-released fix is version 3.11.7.
Sandbox escape in the vm2 npm library versions 3.10.2 through 3.11.6, when running on Node.js 26, allows attacker-supplied JavaScript to break out of the sandbox and reach the host Function constructor and process object, resulting in arbitrary code execution. The escape is unauthenticated and requires no special vm2 configuration - no require.external, builtin allowlists, or unsafe options - but it is gated on the Node.js 26 / V8 14.6 runtime, so the same vm2 versions on other Node.js major versions are not affected by this finding. No public exploit code and no confirmed active exploitation were identified at time of analysis; the practical prerequisite is that a deployment accepts and executes untrusted code inside vm2, which is the library's core threat model.
Denial of service in vm2 through 3.11.6 lets sandboxed JavaScript escape the VM({ timeout }) accounting and block the host event loop indefinitely. Because FinalizationRegistry and WeakRef are exposed to the sandbox unmodified (they are not among the hardened globals in lib/setup-sandbox.js) and the timeout only wraps the single _runScript() call via doWithTimeout() in lib/vm.js, sandboxed code can register a FinalizationRegistry cleanup callback, drop the last strong reference to the target object, and return from vm.run() well within the configured timeout; when V8 later reclaims the object it invokes the sandboxed callback with no timeout in effect, so a busy loop there hangs the host process for an unbounded period. Exploitation requires a host application that executes attacker-controlled JavaScript inside vm2 and relies on VM({timeout}) as its resource-exhaustion control - vm2's intended use case. Impact is availability only (no sandbox escape, code execution, or data disclosure), and no public exploit identified at time of analysis; the main practical limiter is that GC timing is non-deterministic and only loosely influenced by the attacker via memory pressure or --expose-gc.
Sandbox escape in vm2 3.11.3 through 3.11.6 lets JavaScript executing inside a NodeVM instance reach the host tls module and call tls.setDefaultCACertificates(), overwriting the process-wide default certificate authority store so that subsequent host HTTPS clients will accept attacker-supplied certificates. The flaw is config-gated rather than a default-configuration remote exploit: the host application must both run attacker-controlled JavaScript inside vm2 and expli(他)citly add the 'tls' and 'url' modules to the sandbox builtin allowlist, which is not vm2's default builtin set, and meaningful data compromise additionally requires the attacker to hold a network man-in-the-middle position to present the newly trusted forged certificate. Consistent with those prerequisites, our assessment scores this as CVSS 3.1 AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:L (unauthenticated from the network, but high attack complexity and scope-changing sandbox-integrity impact) rather than the unmodified 10.0 of the supplied CVSS 4.0 vector; no public exploit code and no confirmed active exploitation were identified at time of analysis.
Credential disclosure and HTTPS session hijacking in vm2 3.11.3 through 3.11.6 allow sandboxed JavaScript to read host Authorization headers, private destination host/port information, and subsequent plaintext response bodies when a NodeVM is explicitly configured to allow require('https') and the host process concurrently issues outbound HTTPS requests. The vendor rates this CVSS 4.0 10.0, but our independent assessment scores it CVSS 3.1 AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:L/A:N; exploitation requires the non-default require('https') configuration plus opportunistic timing when pooled host connections emit the 'free' event. There is no public exploit identified at time of analysis, and no CISA KEV confirmation was provided in the intelligence.
Sandbox escape and arbitrary native code execution in vm2 3.11.3 through 3.11.6 occurs when a NodeVM sandbox is configured to allow the host crypto builtin: sandboxed JavaScript can reach crypto.setEngine() and hand it a filesystem path pointing at an attacker-supplied shared library (for example one shipped inside an untrusted plugin package already unpacked to disk), which OpenSSL passes to the operating system's dynamic loader and whose constructor then executes in the host process. Exploitation needs the crypto builtin alone - fs, process, module, child_process, worker_threads, vm and inspector access are all unnecessary - and there is no public exploit code or confirmed active exploitation (no CISA KEV listing) at time of analysis, though the reporter-assigned score of 9.4 reflects the severity if those prerequisites are met. Real-world urgency is gated by deployment-specific factors: the crypto builtin must be explicitly exposed to the sandbox and the host must already contain an attacker-writable native library, so a patched release or a tightened builtin allow-list fully removes the attack surface.
Native code execution outside the sandbox affects vm2 versions 3.11.3 through 3.11.6 when the host node:sqlite builtin is exposed to a NodeVM sandbox - either explicitly or through the wildcard builtin: ['*'] - which is not a default configuration. Sandboxed plugin code can create an in-memory DatabaseSync with extension loading turned on, resolve an attacker-supplied native library via a __dirname-derived path, and call loadExtension(), causing SQLite to load that library into the Node.js host process and execute its native entry point with host privileges; the vm.readonly() wrapper prevents property assignment but leaves host-authority callables reachable, and a 'node:node:sqlite' double-prefix quirk in the resolver/prefix-stripping logic lets the sandbox reach the configured builtin. There is no public exploit identified at time of analysis and no confirmed active exploitation (CISA KEV) - the vendor released vm2 3.11.7 to fix it. Real-world priority is strongly gated by configuration: exploitation requires all of permitting node:sqlite in the sandbox, enabling SQLite extension loading, and having an attacker-controlled .so/.dll on disk within the plugin package.
Sandbox escape leading to remote code execution in vm2 3.11.6 lets untrusted code inside the sandbox reach a live proxy to a host-realm object and run commands with the host process privileges, for example through e.detail.mainModule.require('child_process').execSync(...). The flaw is an incomplete fix for GHSA-m283-3h24-438v: registering a rejection handler via Function.prototype.call or .apply indirection (p.then.call(p, undefined, cb)) bypasses the identity check at lib/bridge.js:1624, so the raw host Error and its non-primitive own properties are handed to sandbox code. Exploitation is conditional: the embedder must bridge an async host Promise into the sandbox and that Promise must reject with an Error carrying a non-primitive own property that references a host object (for example err.detail = process); direct p.then(undefined, cb), .bind and Reflect.apply forms are correctly sanitised. Upgrade to vm2 3.11.7 closes the bypass; no public exploit identified at time of analysis.
Sandbox escape and remote code execution in vm2 versions 3.11.4 through 3.11.6 allow JavaScript executed inside a NodeVM to break out and run arbitrary commands with the privileges of the host Node.js process. The flaw is reachable only in a specific, non-default configuration where the NodeVM is created with a truthy `nesting` value and an array-shaped `require` option (for example `new NodeVM({nesting: true, require: []})`); in that case the array satisfies a guard intended to reject nesting without an explicit require configuration, and the resulting resolver falls back to a nesting override that permits the sandboxed code to require the host `vm2` module and construct an inner NodeVM with an attacker-chosen builtin allowlist such as `child_process`. Exploitation requires no authentication or user interaction (CVSS 4.0 vector reports PR:N/UI:N) beyond the ability to supply code the sandbox runs, which is vm2's intended threat model; there is no public exploit code or CISA KEV confirmation of active exploitation at time of analysis, but the impact is complete confidentiality, integrity, and availability loss on the host, and the vendor CVSS 4.0 score of 9.5 is consistent with that assessed impact.
Sandbox escape in vm2 before 3.11.8 allows unauthenticated remote attackers to achieve full remote code execution and host process information disclosure by crafting a host-wrapped AggregateError that is revisited within a single exception-handler traversal, bypassing handleException's cycle detection and exposing unsanitized host proxies in the errors array. The flaw is an incomplete fix for Error.cause sanitization, and exploitation requires the host application to execute attacker-controlled JavaScript inside a vulnerable vm2 instance, which is vm2's normal use case, though the malformed-error and traversal condition is non-trivial (CVSS AC:H/AT:P). No public exploit identified at time of analysis; environments that do not run untrusted code in vm2, or that have migrated off the deprecated vm2, are not exposed.
Sandbox escape in vm2 (patriksimek/vm2) versions prior to 3.11.3 enables remote code execution on the host Node.js process by abusing async generator `yield*` semantics to smuggle a host-realm exception into sandbox code, where the attacker pivots through `.constructor.constructor` to reach `process` and `child_process.execSync`. The flaw is exploitable by any attacker who can run JavaScript inside the sandbox, has publicly available exploit code, and carries SSVC technical impact 'total' with automatable=yes, though EPSS remains low at 0.05% (17th percentile) and the CVE is not listed in CISA KEV.
Full sandbox escape with arbitrary code execution allows remote attackers to break out of vm2's Node.js sandbox environment (version 3.10.4) and execute commands on the host system. Attacker-controlled code running inside VM.run() can obtain the host process object and execute arbitrary host commands without any cooperation from the host application. EPSS data not available, but this represents complete failure of the sandbox security boundary. Patch released in version 3.10.5 addresses eleven distinct escape vectors including Function constructor leakage, proxy unwrapping, util.inspect exposure, and WebAssembly exception handling.
Sandbox escape leading to remote code execution in the vm2 Node.js sandbox library affects all versions prior to 3.11.0, where the JavaScript SuppressedError mechanism (combined with DisposableStack disposal) lets untrusted code running inside the sandbox reach a host constructor and execute arbitrary commands on the underlying server. Any application that relies on vm2 to safely run attacker-controlled or untrusted JavaScript is fully compromised, with a working proof-of-concept published in the GHSA advisory. There is publicly available exploit code but no confirmed active exploitation; the SSVC framework rates it POC, automatable, with total technical impact, while EPSS remains low at 0.06%.
Remote code execution in vm2 (Node.js sandbox library) versions prior to 3.11.0 allows unauthenticated attackers to escape the sandbox environment via the inspect function and execute arbitrary system commands. The vulnerability exploits handler leakage through util.inspect's showProxy option to reconstruct host-realm objects and break isolation guarantees. CRITICAL: This is a complete sandbox bypass affecting all deployments using vm2 for untrusted code execution. Vendor-released patch available in version 3.11.0 with multiple commits addressing eight distinct exploitation primitives discovered during iterative disclosure.
Sandbox escape in vm2 for Node.js allows remote unauthenticated attackers to execute arbitrary commands on the host system. The vulnerability represents an insufficient fix for CVE-2023-37466, enabling attackers to circumvent sandbox protections through multiple attack vectors including Function constructor extraction, proxy unwrapping, property descriptor manipulation, and WebAssembly JSTag exploitation. CVSS 9.8 (Critical) with EPSS data unavailable, but the existence of a detailed security advisory and comprehensive patch from GitHub indicates active vendor awareness and rapid response. Patched in version 3.10.5 with eleven distinct fixes addressing various bypass techniques.
Information disclosure and cross-boundary host memory corruption in vm2 before 3.12.2 let untrusted guest JavaScript read and modify bytes outside the sandbox whenever the embedding application explicitly allowlists Node's zlib builtin via require: { builtin: ['zlib'] }. vm2 fails to apply its Buffer backing-store ownership invariant (byteOffset === 0 && buffer.byteLength === length) to Buffers returned from host builtin modules, so zlib.deflateSync can hand back a pooled buffer whose .buffer getter exposes Node's entire 64 KiB shared small-buffer pool; a guest then builds a full-width view with Buffer.from(result.buffer, 0, result.buffer.byteLength) to disclose secrets (session tokens, decrypted material, DB rows) and corrupt unrelated host buffers sharing that pool. This is not reachable in a default vm2 deployment - it requires a non-default zlib allowlist, attacker-controlled script execution, and host secrets co-resident in the pool at exploitation time - and no public exploit code was identified at time of analysis; the vendor rates it CVSS 4.0 6.9 (Medium) with a vendor-released patch in 3.12.2.
Sandbox escape in vm2 through 3.12.0 lets untrusted guest code cross the NodeVM isolation boundary and change process-wide state by calling crypto.setFips(), which toggles the FIPS mode of the entire host Node.js process (observed as crypto.getFips() flipping from 0 to 1 in the reporter's test). The vulnerability is only reachable when the embedding application runs vm2 as a NodeVM with the non-default, opt-in configuration require.builtin: ['crypto']; authentication and user interaction are not required in that scenario, and the practical impact is limited to low-integrity and low-availability effects rather than arbitrary host code execution or data disclosure. No public exploit identified at time of analysis; the issue is fixed in vm2 3.12.1, available from the vendor (GHSA-x3v6-43hc-82mc).
Untrusted JavaScript running inside a vm2 sandbox before version 3.11.2 can reach the host-side internal state object via globalThis['VM2_INTERNAL_STATE_DO_NOT_USE_OR_PROGRAM_WILL_FAIL'], disclosing sandbox internals that were supposed to be invisible to guest code in the npm package vm2. The issue is a re-bypass of the earlier advisory GHSA-wp5r-2gw5-m7q7, and a short working proof-of-concept is published in the vendor advisory GHSA-2cm2-m3w5-gp2f, so publicly available exploit code exists; no CISA KEV listing appears in the supplied intelligence and no EPSS value was provided. The CVSS 4.0 base score is 6.9 with a confidentiality-only impact (VC:L, VI:N, VA:N, SC:N, PR:N, UI:N), consistent with the independent assessment that this is a genuine but low-severity information disclosure with no demonstrated code execution, integrity, or availability effect; the unauthenticated PR:N rating reflects the vector, while in practice the attacker must already be able to execute code inside the vm2 trust boundary (an application that embeds vm2 and runs attacker-controlled scripts).
Sandboxed JavaScript running in the npm package vm2 3.11.3 and earlier can install an accessor on Array.prototype so that the bridge's defaultSandboxPrepareStackTrace routine writes each stack-trace line through that attacker-controlled setter, allowing in-sandbox code to observe and intercept the formatted stack-trace strings the host builds. The impact is confined to a low-bandwidth information side channel and a violation of vm2's documented bridge-container defense invariant; there is no sandbox escape and no code execution, which is why the vendor rates the issue Low, consistent with a published CVSS 4.0 base score of 2.1 and our assessed CVSS:3.1/AV:L/AC:H/PR:N/UI:N/S:C/C:L/I:N/A:N. The practical precondition is that the host application runs attacker-controlled JavaScript inside a vulnerable vm2 sandbox and that the sandboxed code arrange a prototype setter before error.stack (or any path triggering Error.prepareStackTrace) is read; no public exploit code or active exploitation has been identified at time of analysis, and the assessed vector carries PR:N, meaning no additional privileges beyond sandbox code execution are required.
Sandbox escape and read-only bypass in vm2 3.9.6 through 3.11.6 lets untrusted JavaScript running inside a NodeVM defeat the vm.freeze() and vm.readonly() protections and mutate host object properties that the embedder explicitly marked immutable. An attacker uses Object.getOwnPropertyDescriptor() or __lookupSetter__() to recover host-realm setters from accessor properties on frozen objects and invoke them directly, circumventing the Proxy-based restrictions. The CVSS 4.0 vector (PR:N, AC:H, AT:P, VI:L/SI:L, no C/I/A beyond low integrity) confirms unauthenticated access but high attack complexity and an integrity-only ceiling with no code execution; two prerequisites must hold (untrusted code executed in vm2, and reliance on vm.freeze()/vm.readonly() to protect reachable host objects). No public exploit identified at time of analysis, there is no CISA KEV listing, and vm2 is deprecated, which further narrows realistic exposure to legacy deployments using versions 3.9.6 to 3.11.6.
Module allowlist bypass in vm2 before 3.11.7 lets JavaScript that is already executing inside the sandbox load packages the host intended to forbid, by performing a relative require from an allowlisted package to a non-allowlisted package whose resolved path only shares a leading string prefix with an allowlisted module. Exploitation is not remote or automatic: it requires the host application to deliberately run untrusted code in vm2, an enforced module allowlist combined with disabled transitive loading, and a prefix-collision package layout, which is why our independent assessment scores it as a low-severity, high-complexity weakness (CVSS 3.1 AV:N/AC:H/PR:L/UI:N/S:U/C:L/I:L/A:N, attack requirements present) rather than a sandbox escape; there is no public exploit identified at time of analysis and no confirmed active exploitation (no CISA KEV listing).
Absolute host filesystem path disclosure in vm2 3.11.0 through 3.11.6 allows attacker-supplied JavaScript running inside a vm2 sandbox to force the host-realm source transformer to throw a SyntaxError (for example via eval with malformed source) and then read the resulting error's .stack property, which the bridge forwards to the host-realm formatter. Default new VM() and new NodeVM() configurations are affected with no special options, and the leak persists even when string eval is disabled, because the host-side transformer throws before eval is handled. Only information disclosure results - absolute paths from vm2, Node.js internals, and the embedding application's source tree plus host function names - with no write, no code execution, and no public exploit identified at time of analysis; the CVSS 4.0 score of 6.9 reflects the scope change and low confidentiality impact rather than a high-severity outcome.
Information disclosure in vm2 through version 3.11.7 allows sandboxed Node.js code to read the host process's call stack metadata: NodeVM exposes the host util module as an unfiltered shallow copy and also exposes the deprecated sys alias, and on Node.js 22.9 or later this hands sandbox code util.getCallSites(), which returns absolute file paths, function names, and line numbers for vm2 bridge internals and the embedding application's entrypoint. Remote attackers are unauthenticated (CVSS PR:N), but exploitation requires the host application to actually execute attacker-controlled JavaScript inside NodeVM and to be running Node.js >= 22.9; the leak is read-only and grants no code execution or write access. Vendor-released patch: vm2 3.11.8. No confirmed active exploitation (no CISA KEV listing) and no public exploit code identified at time of analysis.