vm2 Advisory: Sandbox Escape Extends Host-Intrinsic Pollution to TypedArray and ArrayBuffer Prototypes

What Happened

A new security advisory (GHSA-3vgf-8m4q-q4qr, tracked as CVE-2026-92953, CVSS 10.0) reports that vm2's fix for a prior host-prototype pollution issue (GHSA-vwrp-x96c-mhwq) was incomplete. According to the advisory, the earlier patch protects classic host intrinsics like Object.prototype, Array.prototype, and Function.prototype from sandbox writes, but the protected-object inventory in lib/bridge.js never included typed-array and ArrayBuffer intrinsics. As a result, code running in a default vm2 VM (no NodeVM, no require.builtin, no nesting: true) can reportedly reach and mutate Uint8Array.prototype, %TypedArray%.prototype, and ArrayBuffer.prototype on the host realm using the same prototype-walking primitive (via Buffer and __lookupGetter__) disclosed in the earlier advisory. A public PoC is referenced in the advisory, and the author describes the issue as confirmed on current head (v3.11.5) and on the already-patched-adjacent v3.11.0–3.11.5 range.

Why It Matters

vm2 is widely used to run untrusted JavaScript in a sandbox inside Node.js applications — plugin systems, code-execution services, CI tooling, and similar use cases. Per the advisory, this flaw lets sandboxed code corrupt shared host typed-array and ArrayBuffer prototypes, so that ordinary host-created typed arrays and buffers observe attacker-installed properties and methods after VM.run() returns. The advisory frames this as an integrity/availability issue (prototype pollution affecting shared binary-data handling across the host process), not confirmed direct code execution outside the sandbox or confidentiality impact. Any application that still trusts vm2's default VM isolation to contain untrusted code — including after applying the prior host-intrinsic pollution fix — should treat this as unresolved exposure, since the advisory states the protected-object inventory is simply missing this intrinsic family rather than having a different root cause.

What Defenders Should Do Now

• Inventory where vm2 is used to execute untrusted or semi-trusted JavaScript, and confirm whether it relies on the default VM (affected per the advisory) versus other isolation.
• Treat vm2 as providing weaker sandbox guarantees than documented until an upstream fix lands; consider defense-in-depth (OS-level sandboxing, separate processes/containers, or migrating to actively maintained isolation technology) for untrusted code execution.
• At a detection/hunting level, watch for anomalous mutation of built-in prototypes (Object.getOwnPropertyDescriptor changes on Uint8Array.prototype, ArrayBuffer.prototype, etc.) in application telemetry or runtime integrity checks, and for unexpected use of __lookupGetter__/__proto__ walking patterns in logged or sandboxed script input where that can be captured.
• Review any code that depends on vm2's host-intrinsic protection as a security boundary and avoid assuming it is comprehensive — per the advisory, the enforcement mechanism (bridge traps on set/defineProperty/deleteProperty/preventExtensions) is sound but the inventory of protected objects was incomplete once already.

Developing Intel

This is net-new, same-day intelligence based on a single GHSA advisory; there is no vendor patch confirmed in the material reviewed here, and details may evolve. Review the original advisory for the full technical writeup and PoC: GHSA-3vgf-8m4q-q4qr.