A critical flaw in the vm2 Node.js sandbox lets untrusted code inside the sandbox reach out and mutate host TypedArray and ArrayBuffer prototypes, corrupting the host process after execution returns.
What Is It
vm2 fails to protect host TypedArray and ArrayBuffer prototypes from mutation by sandboxed code. Attackers can use prototype-walking primitives to reach and modify host Uint8Array.prototype, %TypedArray%.prototype, and ArrayBuffer.prototype. The consequence is that host-created typed arrays observe attacker-controlled properties after VM.run() has returned; meaning the sandbox boundary does not hold, and contamination outlives the sandboxed call.
The issue is classified as CWE-913 (Improper Control of Dynamically-Managed Code Resources). It was disclosed via VulnCheck and published on 2026-09-17.
Why It Matters
The CVSS v3.1 base score is 10.0 (CRITICAL), vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:N/I:H/A:H, network attack vector, low complexity, no privileges, no user interaction, and a changed scope, reflecting that the impact crosses the sandbox boundary into the host. The secondary CVSS v4.0 score is 9.3 (CRITICAL), with high integrity and availability impact to both the vulnerable system and downstream subsequent systems.
vm2 is widely used precisely to run untrusted or semi-trusted JavaScript. Any deployment that accepts attacker-supplied code, plugin runtimes, serverless evaluation layers, low-code platforms, should treat this as a full escape of the isolation guarantee it was deployed to provide.
This CVE does not appear in the CISA Known Exploited Vulnerabilities catalog (https://www.cisa.gov/known-exploited-vulnerabilities-catalog), so active exploitation is not confirmed and no federal remediation deadline applies. Exploit maturity in the CVSS v4.0 vector is NOT_DEFINED.
What's Vulnerable
- Vendor: patriksimek
- Product: vm2 (
pkg:npm/vm2) - Advisory-stated affected range: >= 3.11.0, < 3.11.8, unverified, see below
- Advisory-stated fixed version: 3.11.8, unverified, see below
The version data in the advisory does not match the package's published release history. vm2 has no 3.11.x release line on npm; its published releases end in the 3.9.x series (https://www.npmjs.com/package/vm2?activeTab=versions). The 3.11.0–3.11.7 range and the 3.11.8 fixed version therefore cannot be confirmed against any shipped artifact, and should be treated as unreliable until the advisory is corrected or clarified.
No CPE entries were listed in the NVD record; the version ranges above come from the vendor-supplied affected-product data rather than from independently verified package metadata.
Patch Status
The advisory names 3.11.8 as the fixed version, but no such release exists on npm, so there is no upgrade target that can be verified from the public registry. Operators should check their installed vm2 version directly against the published releases and track the upstream advisory for corrected version data. NVD lists the record's vulnStatus as Deferred.
Given the scope-changed, unauthenticated nature of the flaw, and that no workaround is described in the supplied source material, deployments running untrusted JavaScript under vm2 should assume the isolation guarantee is unreliable and plan migration to a maintained isolation mechanism rather than waiting on a version bump.
Sources
- NVD, CVE-2026-92953: https://nvd.nist.gov/vuln/detail/CVE-2026-92953
- GitHub Security Advisory GHSA-3vgf-8m4q-q4qr: https://github.com/patriksimek/vm2/security/advisories/GHSA-3vgf-8m4q-q4qr
- VulnCheck Advisory: https://www.vulncheck.com/advisories/vm2-3.11.0-through-3.11.7-prototype-pollution-via-typedarray
- CISA Known Exploited Vulnerabilities Catalog: https://www.cisa.gov/known-exploited-vulnerabilities-catalog
- vm2 published versions on npm: https://www.npmjs.com/package/vm2?activeTab=versions