vm2
Ecosystem: npm
Downloads: 4.41 Mln
- 70CriticalAffects 70 versions
- 19HighAffects 19 versions
- 0MediumAffects 0 versions
- 16ModerateAffects 16 versions
- 2LowAffects 2 versions
- Critical70 (65.4%)
- High19 (17.8%)
- Medium0 (0.0%)
- Moderate16 (15.0%)
- Low2 (1.9%)
Monthly breakdown
- Critical
- High
- Medium
- Moderate
- Low
- 30 vulnerabilities
- Critical: 19
- High: 5
- Medium: 0
- Moderate: 6
- Low: 0
- 29 vulnerabilities
- Critical: 19
- High: 5
- Medium: 0
- Moderate: 4
- Low: 1
- 5 vulnerabilities
- Critical: 3
- High: 2
- Medium: 0
- Moderate: 0
- Low: 0
- 30 vulnerabilities
- Critical: 18
- High: 6
- Medium: 0
- Moderate: 5
- Low: 1
- 1 vulnerabilities
- Critical: 1
- High: 0
- Medium: 0
- Moderate: 0
- Low: 0
- 2 vulnerabilities
- Critical: 2
- High: 0
- Medium: 0
- Moderate: 0
- Low: 0
- 2 vulnerabilities
- Critical: 1
- High: 0
- Medium: 0
- Moderate: 1
- Low: 0
- 3 vulnerabilities
- Critical: 3
- High: 0
- Medium: 0
- Moderate: 0
- Low: 0
- 1 vulnerabilities
- Critical: 1
- High: 0
- Medium: 0
- Moderate: 0
- Low: 0
- 1 vulnerabilities
- Critical: 1
- High: 0
- Medium: 0
- Moderate: 0
- Low: 0
- 1 vulnerabilities
- Critical: 0
- High: 1
- Medium: 0
- Moderate: 0
- Low: 0
- 1 vulnerabilities
- Critical: 1
- High: 0
- Medium: 0
- Moderate: 0
- Low: 0
- 1 vulnerabilities
- Critical: 1
- High: 0
- Medium: 0
- Moderate: 0
- Low: 0
Vulnerabilities (107)
Known vulnerabilities affecting vm2, based on data from OSV.
| ID | Severity | Summary | Affected versions | Published | Source |
|---|---|---|---|---|---|
| GHSA-pq68-rvw4-xp4r | Critical | vm2 contains a sandbox escape vulnerabilityvm2 NodeVM versions before 3.12.1 contain a sandbox escape vulnerability where the DANGEROUS_BUILTINS denylist omits child_process despite blocking other host-spawning modules. Attackers can require child_process and execute arbitrary commands on the host system when NodeVM is configured with builtin:['*'] or explicit child_process allowance. This fork hardens `NodeVM` with a `DANGEROUS_BUILTINS` denylist that blocks host‑code‑reaching core modules **even when the sandbox requests `builtin:['*']` or names them explicitly** — the list contains `module`, `worker_threads`, `cluster`, `vm`, `repl |
| GitHub (opens in a new tab) | |
| GHSA-2v2p-6j97-cjg9 | High | vm2: Host Promise rejection from an exposed constructor can terminate the vm2 host process## Summary An untrusted script run by `VM.run` can construct an embedder-exposed host function that returns a rejected native Promise and ignore the result. The sandbox-to-host `construct` trap forwards that Promise without applying the host-side rejection handling already used by the neighboring `apply` trap, so Node's strict unhandled-rejection policy terminates the host process. ## Technical Details The precondition is an application-supplied constructable host function in the VM sandbox whose constructor body returns a native rejected Promise. In JavaScript, an object explicitly returne |
| GitHub (opens in a new tab) | |
| GHSA-3vgf-8m4q-q4qr | Critical | vm2: Default VM can mutate host TypedArray and ArrayBuffer intrinsics after the host-prototype pollution fix## Summary vm2's current host-intrinsic prototype protection is incomplete. The fix for `GHSA-vwrp-x96c-mhwq` blocks sandbox writes into classic host intrinsics such as `Object.prototype`, `Array.prototype`, and `Function.prototype`, but current head still lets sandbox code in a default `VM` reach and mutate host `Uint8Array.prototype`, `%TypedArray%.prototype`, and `ArrayBuffer.prototype`. After `VM.run()` returns, normal host typed-array and ArrayBuffer objects observe attacker-controlled properties and methods installed by the sandbox. ## Technical Details The existing mitigation relies |
| GitHub (opens in a new tab) | |
| GHSA-489w-w794-jq94 | Moderate | vm2: NodeVM zlib Buffers expose pooled host memory across the VM boundary## Summary When an application explicitly exposes Node's `zlib` module through vm2's `NodeVM` builtin allowlist, an untrusted guest can obtain a pool-backed host `Buffer` from `zlib.deflateSync`, create a full-width view of its backing `ArrayBuffer`, read bytes outside the compressed result, and flip a byte in an unrelated host buffer. The pinned vm2 revision reproduces disclosure and host-memory modification, while a sandbox-local `Buffer` control remains exact-size and non-mutating. ## Technical Details `NodeVM` accepts `require: { builtin: ['zlib'] }`. The builtin resolver reaches `addDe |
| GitHub (opens in a new tab) | |
| GHSA-5h3f-q97h-ccvc | Critical | vm2: NodeVM custom resolution bypasses external path boundaries## Summary At source revision `91034466bfb7f56b95fd48083ec6ca36d058f164` of vm2 3.11.8, an untrusted `NodeVM` guest can turn one allowlisted custom-resolved module into authorization for a separate file whose path merely shares the resolved path's string prefix. `LegacyResolver.customResolve` stores the resolved path in `this.externals` as `^<path>` without an end or separator boundary; a later absolute require of a sibling such as `foo2/index.js` therefore passes the external check and is loaded through `hostRequire` when the configured context is `host`. The decisive attack loaded `foo` as |
| GitHub (opens in a new tab) | |
| GHSA-88hf-g992-jg85 | Critical | vm2: Sandbox Escape (NodeVM)## Summary It being possible to obtain the host `__proto__` getter/setter, has been used in many reports: - https://github.com/patriksimek/vm2/security/advisories/GHSA-vwrp-x96c-mhwq - https://github.com/patriksimek/vm2/security/advisories/GHSA-v6mx-mf47-r5wg - https://github.com/patriksimek/vm2/security/advisories/GHSA-grj5-jjm8-h35p - https://github.com/patriksimek/vm2/security/advisories/GHSA-47x8-96vw-5wg6 Yet it was never patched... --- This can, still, be used to escape the sandbox, one example (I'm sure there's other ways as well), is via `console._stdout`/`console._stderr` (`NodeV |
| GitHub (opens in a new tab) | |
| GHSA-f8gf-w286-fmq2 | High | vm2: `allowAsync: false` can be bypassed through Promise thenable assimilation in VM and NodeVM### Summary When `allowAsync` is set to `false`, vm2 is expected to reject attempts to run asynchronous code. Direct use of `Promise.prototype.then` is blocked, but Promise static methods still assimilate attacker-controlled thenables. `Promise.resolve(thenable)`, `Promise.all([thenable])`, `Promise.race([thenable])`, `Promise.any([thenable])`, and `Promise.allSettled([thenable])` can invoke the thenable's `then` method in a microtask after `VM.run()` or `NodeVM.run()` has already returned. This bypasses the documented async-execution restriction and runs outside the configured `timeout`, al |
| GitHub (opens in a new tab) | |
| GHSA-fcqc-726x-5wfc | Critical | vm2: Sandboxed code can read and write host-realm memory via Node's shared Buffer pool### Summary Sandboxed code is able to disclose host memory used by small allocations by `Buffer.from`, `Buffer.concat`. ### Details vm2 exposes `Buffer` object to sandboxed code by default. Small [`Buffer` allocations](https://nodejs.org/api/buffer.html#static-method-bufferallocunsafesize) (for example, [Buffer.allocUnsafe()](https://nodejs.org/api/buffer.html#static-method-bufferallocunsafesize), [Buffer.from(array)](https://nodejs.org/api/buffer.html#static-method-bufferfromarray), [Buffer.from(string)](https://nodejs.org/api/buffer.html#static-method-bufferfromstring-encoding), and [Buffer |
| GitHub (opens in a new tab) | |
| GHSA-gjq8-xm47-88rc | Critical | vm2: Host-returned Promise rejection can bypass vm2's unhandled-rejection hardening and terminate the host process## Summary vm2 current head (`v3.11.5`, commit `7a1f5100b96f48d34e0fe104ab37c0acc5944f92`) can still be used to terminate the host Node.js process when sandbox code calls a host-realm function that returns a rejected host Promise and then ignores the returned value. This is an incomplete-fix variant of the `GHSA-hw58-p9xv-2mjh` unhandled rejection hardening. The `localPromise` constructor now catches and consumes sandbox-created unhandled rejections, but host Promises returned across the bridge are not marked handled at the bridge boundary. If the sandbox does not attach `.catch()` or `.then |
| GitHub (opens in a new tab) | |
| GHSA-j3hm-6rg5-mchv | Critical | vm2: NodeVM `require.external` without an explicit `require.root` grants unrestricted host filesystem access and full RCE## Summary `NodeVM`'s `require.external` option lets sandboxed code `require()` local files and npm packages. When `require.external` is enabled and `require.root` is **not explicitly set to a path that excludes `node_modules`**, two defaults combine to fully defeat the sandbox: - `require.root` defaults to **unrestricted** — "if omitted every path is allowed." - `require.context` defaults to **`"host"`** — files loaded this way run through the **real Node.js `require()`**, not inside any vm2 sandbox. Sandboxed code can therefore `require()` a relative or absolute path to vm2's own installe |
| GitHub (opens in a new tab) |
- GHSA-pq68-rvw4-xp4rCriticalvm2 contains a sandbox escape vulnerability
< 3.12.1
vm2 NodeVM versions before 3.12.1 contain a sandbox escape vulnerability where the DANGEROUS_BUILTINS denylist omits child_process despite blocking other host-spawning modules. Attackers can require child_process and execute arbitrary commands on the host system when NodeVM is configured with builtin:['*'] or explicit child_process allowance. This fork hardens `NodeVM` with a `DANGEROUS_BUILTINS` denylist that blocks host‑code‑reaching core modules **even when the sandbox requests `builtin:['*']` or names them explicitly** — the list contains `module`, `worker_threads`, `cluster`, `vm`, `repl
CVE: CVE-2026-93605
- GHSA-2v2p-6j97-cjg9Highvm2: Host Promise rejection from an exposed constructor can terminate the vm2 host process
< 3.12.2
## Summary An untrusted script run by `VM.run` can construct an embedder-exposed host function that returns a rejected native Promise and ignore the result. The sandbox-to-host `construct` trap forwards that Promise without applying the host-side rejection handling already used by the neighboring `apply` trap, so Node's strict unhandled-rejection policy terminates the host process. ## Technical Details The precondition is an application-supplied constructable host function in the VM sandbox whose constructor body returns a native rejected Promise. In JavaScript, an object explicitly returne
CVE: CVE-2026-100722
- GHSA-3vgf-8m4q-q4qrCriticalvm2: Default VM can mutate host TypedArray and ArrayBuffer intrinsics after the host-prototype pollution fix
>= 3.11.0, < 3.11.8
## Summary vm2's current host-intrinsic prototype protection is incomplete. The fix for `GHSA-vwrp-x96c-mhwq` blocks sandbox writes into classic host intrinsics such as `Object.prototype`, `Array.prototype`, and `Function.prototype`, but current head still lets sandbox code in a default `VM` reach and mutate host `Uint8Array.prototype`, `%TypedArray%.prototype`, and `ArrayBuffer.prototype`. After `VM.run()` returns, normal host typed-array and ArrayBuffer objects observe attacker-controlled properties and methods installed by the sandbox. ## Technical Details The existing mitigation relies
CVE: CVE-2026-92953
- GHSA-489w-w794-jq94Moderatevm2: NodeVM zlib Buffers expose pooled host memory across the VM boundary
< 3.12.2
## Summary When an application explicitly exposes Node's `zlib` module through vm2's `NodeVM` builtin allowlist, an untrusted guest can obtain a pool-backed host `Buffer` from `zlib.deflateSync`, create a full-width view of its backing `ArrayBuffer`, read bytes outside the compressed result, and flip a byte in an unrelated host buffer. The pinned vm2 revision reproduces disclosure and host-memory modification, while a sandbox-local `Buffer` control remains exact-size and non-mutating. ## Technical Details `NodeVM` accepts `require: { builtin: ['zlib'] }`. The builtin resolver reaches `addDe
CVE: CVE-2026-100723
- GHSA-5h3f-q97h-ccvcCriticalvm2: NodeVM custom resolution bypasses external path boundaries
< 3.12.2
## Summary At source revision `91034466bfb7f56b95fd48083ec6ca36d058f164` of vm2 3.11.8, an untrusted `NodeVM` guest can turn one allowlisted custom-resolved module into authorization for a separate file whose path merely shares the resolved path's string prefix. `LegacyResolver.customResolve` stores the resolved path in `this.externals` as `^<path>` without an end or separator boundary; a later absolute require of a sibling such as `foo2/index.js` therefore passes the external check and is loaded through `hostRequire` when the configured context is `host`. The decisive attack loaded `foo` as
CVE: CVE-2026-100721
## Summary It being possible to obtain the host `__proto__` getter/setter, has been used in many reports: - https://github.com/patriksimek/vm2/security/advisories/GHSA-vwrp-x96c-mhwq - https://github.com/patriksimek/vm2/security/advisories/GHSA-v6mx-mf47-r5wg - https://github.com/patriksimek/vm2/security/advisories/GHSA-grj5-jjm8-h35p - https://github.com/patriksimek/vm2/security/advisories/GHSA-47x8-96vw-5wg6 Yet it was never patched... --- This can, still, be used to escape the sandbox, one example (I'm sure there's other ways as well), is via `console._stdout`/`console._stderr` (`NodeV
CVE: CVE-2026-92955
- GHSA-f8gf-w286-fmq2Highvm2: `allowAsync: false` can be bypassed through Promise thenable assimilation in VM and NodeVM
< 3.11.8
### Summary When `allowAsync` is set to `false`, vm2 is expected to reject attempts to run asynchronous code. Direct use of `Promise.prototype.then` is blocked, but Promise static methods still assimilate attacker-controlled thenables. `Promise.resolve(thenable)`, `Promise.all([thenable])`, `Promise.race([thenable])`, `Promise.any([thenable])`, and `Promise.allSettled([thenable])` can invoke the thenable's `then` method in a microtask after `VM.run()` or `NodeVM.run()` has already returned. This bypasses the documented async-execution restriction and runs outside the configured `timeout`, al
CVE: CVE-2026-92959
- GHSA-fcqc-726x-5wfcCriticalvm2: Sandboxed code can read and write host-realm memory via Node's shared Buffer pool
< 3.11.7
### Summary Sandboxed code is able to disclose host memory used by small allocations by `Buffer.from`, `Buffer.concat`. ### Details vm2 exposes `Buffer` object to sandboxed code by default. Small [`Buffer` allocations](https://nodejs.org/api/buffer.html#static-method-bufferallocunsafesize) (for example, [Buffer.allocUnsafe()](https://nodejs.org/api/buffer.html#static-method-bufferallocunsafesize), [Buffer.from(array)](https://nodejs.org/api/buffer.html#static-method-bufferfromarray), [Buffer.from(string)](https://nodejs.org/api/buffer.html#static-method-bufferfromstring-encoding), and [Buffer
CVE: CVE-2026-92947
- GHSA-gjq8-xm47-88rcCriticalvm2: Host-returned Promise rejection can bypass vm2's unhandled-rejection hardening and terminate the host process
>= 3.10.0, < 3.11.8
## Summary vm2 current head (`v3.11.5`, commit `7a1f5100b96f48d34e0fe104ab37c0acc5944f92`) can still be used to terminate the host Node.js process when sandbox code calls a host-realm function that returns a rejected host Promise and then ignores the returned value. This is an incomplete-fix variant of the `GHSA-hw58-p9xv-2mjh` unhandled rejection hardening. The `localPromise` constructor now catches and consumes sandbox-created unhandled rejections, but host Promises returned across the bridge are not marked handled at the bridge boundary. If the sandbox does not attach `.catch()` or `.then
CVE: CVE-2026-92954
- GHSA-j3hm-6rg5-mchvCriticalvm2: NodeVM `require.external` without an explicit `require.root` grants unrestricted host filesystem access and full RCE
< 3.11.7
## Summary `NodeVM`'s `require.external` option lets sandboxed code `require()` local files and npm packages. When `require.external` is enabled and `require.root` is **not explicitly set to a path that excludes `node_modules`**, two defaults combine to fully defeat the sandbox: - `require.root` defaults to **unrestricted** — "if omitted every path is allowed." - `require.context` defaults to **`"host"`** — files loaded this way run through the **real Node.js `require()`**, not inside any vm2 sandbox. Sandboxed code can therefore `require()` a relative or absolute path to vm2's own installe
CVE: CVE-2026-92946