vm2

Ecosystem: npm

Downloads: 4.41 Mln

Vulnerabilities from the last (months)
  • 70CriticalAffects 70 versions
  • 19HighAffects 19 versions
  • 0MediumAffects 0 versions
  • 16ModerateAffects 16 versions
  • 2LowAffects 2 versions
Severity distribution (all time)
107vulnerabilities
  • 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.

Vulnerabilities affecting vm2
IDSeveritySummaryAffected versionsPublishedSource
GHSA-pq68-rvw4-xp4rCriticalvm2 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
  • < 3.12.1
GitHub (opens in a new tab)
GHSA-2v2p-6j97-cjg9Highvm2: 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
  • < 3.12.2
GitHub (opens in a new tab)
GHSA-3vgf-8m4q-q4qrCriticalvm2: 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
  • >= 3.11.0, < 3.11.8
GitHub (opens in a new tab)
GHSA-489w-w794-jq94Moderatevm2: 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
  • < 3.12.2
GitHub (opens in a new tab)
GHSA-5h3f-q97h-ccvcCriticalvm2: 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
  • < 3.12.2
GitHub (opens in a new tab)
GHSA-88hf-g992-jg85Criticalvm2: 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
  • < 3.11.8
GitHub (opens in a new tab)
GHSA-f8gf-w286-fmq2Highvm2: `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
  • < 3.11.8
GitHub (opens in a new tab)
GHSA-fcqc-726x-5wfcCriticalvm2: 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
  • < 3.11.7
GitHub (opens in a new tab)
GHSA-gjq8-xm47-88rcCriticalvm2: 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
  • >= 3.10.0, < 3.11.8
GitHub (opens in a new tab)
GHSA-j3hm-6rg5-mchvCriticalvm2: 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
  • < 3.11.7
GitHub (opens in a new tab)
  • GHSA-pq68-rvw4-xp4rCritical
    vm2 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-cjg9High
    vm2: 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-q4qrCritical
    vm2: 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-jq94Moderate
    vm2: 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-ccvcCritical
    vm2: 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

  • GHSA-88hf-g992-jg85Critical
    vm2: Sandbox Escape (NodeVM)
    • < 3.11.8

    ## 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-fmq2High
    vm2: `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-5wfcCritical
    vm2: 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-88rcCritical
    vm2: 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-mchvCritical
    vm2: 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

Showing 1-10 of 107 vulnerabilities