Patriksimek

CVE	Summary	Severity	CVSS	EPSS	Priority	Signals
CVE-2026-92957	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.	CRITICAL	9.4	0.5%	67	PoC
CVE-2026-93603	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.	CRITICAL	10.0	0.4%	50
CVE-2026-93605	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.	CRITICAL	10.0	0.4%	50
CVE-2026-92937	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.	CRITICAL	10.0	0.8%	50	PoC
CVE-2026-92940	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.	CRITICAL	10.0	0.3%	50	PoC
CVE-2026-92941	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.	CRITICAL	10.0	0.3%	50	PoC
CVE-2026-92946	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.	CRITICAL	10.0	0.6%	50
CVE-2026-92947	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.	CRITICAL	10.0	0.4%	50
CVE-2026-92955	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.	CRITICAL	10.0	0.6%	50
CVE-2026-92956	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.	CRITICAL	10.0	0.4%	50
CVE-2026-92960	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.	CRITICAL	10.0	0.4%	50
CVE-2026-93606	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.	CRITICAL	10.0	0.5%	50
CVE-2026-100721	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.	CRITICAL	9.5	0.4%	48
CVE-2026-92934	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.	CRITICAL	9.5	0.7%	48
CVE-2026-92935	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.	CRITICAL	9.5	0.5%	48	PoC

CVE-2026-92957

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.

CRITICAL

9.4

0.5%

67

PoC

CVE-2026-93603

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.

CRITICAL

10.0

0.4%

50

CVE-2026-93605

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.

CRITICAL

10.0

0.4%

50

CVE-2026-92937

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.

CRITICAL

10.0

0.8%

50

PoC

CVE-2026-92940

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.

CRITICAL

10.0

0.3%

50

PoC

CVE-2026-92941

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.

CRITICAL

10.0

0.3%

50

PoC

CVE-2026-92946

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.

CRITICAL

10.0

0.6%

50

CVE-2026-92947

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.

CRITICAL

10.0

0.4%

50

CVE-2026-92955

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.

CRITICAL

10.0

0.6%

50

CVE-2026-92956

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.

CRITICAL

10.0

0.4%

50

CVE-2026-92960

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.

CRITICAL

10.0

0.4%

50

CVE-2026-93606

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.

CRITICAL

10.0

0.5%

50

CVE-2026-100721

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.

CRITICAL

9.5

0.4%

48

CVE-2026-92934

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.

CRITICAL

9.5

0.7%

48

CVE-2026-92935

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.

CRITICAL

9.5

0.5%

48

PoC

Severity Breakdown

Monthly CVE Trend

Affected Products (4)

Top Risky CVEs