vm2 EUVD-2026-26987

No special conditions - remote unauthenticated exploitation against default configurations of vm2 versions <3.11.0. Attack vector is network-accessible (AV:N) with low complexity (AC:L), requires no privileges (PR:N), and no user interaction (UI:N). The vulnerability exists in core sandbox isolation logic, not dependent on non-default settings, specific Node.js flags, or particular deployment configurations. Exploitation requires only the ability to submit JavaScript code for execution within a vm2 sandbox, which is the library's intended use case. The Buffer.prototype.inspect harvest mechanism functions on Node.js ≤22 (Node 24+ has inadvertent argument validation mitigation for this specific primitive, but the handler leak architecture remains exploitable via alternative paths). The vendor's test suite demonstrates exploitation succeeds across common deployment scenarios without environment-specific prerequisites. Limiting factor: attacker must have code submission capability to the vm2 sandbox, but this is precisely the use case vm2 advertises (running untrusted third-party code), meaning the attack surface is inherent to the product's security promise, not an edge case configuration.

CRITICAL real-world risk despite absence from CISA KEV. CVSS 9.8 (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H) accurately reflects exploitability: network-accessible, low complexity, no authentication, no user interaction required. The exploit is fully weaponized with public proof-of-concept code in the GitHub advisory (GHSA-v37h-5mfm-c47c) and repository test suite demonstrating eight working exploitation primitives. Any application accepting untrusted code for evaluation via vm2 <3.11.0 is immediately vulnerable to complete host system compromise. SSVC decision framework: Exploitation=POC, Automatable=YES (can be scripted without human interaction), Technical Impact=Total (full control of host process). The vulnerability's criticality is amplified by vm2's deployment context - it is explicitly marketed as a security boundary for untrusted code execution, meaning adopters are specifically running attacker-controlled input. Contrast with typical code injection: this is not misuse of a general-purpose API but a complete failure of the library's sole security function. The extensive commit history (three separate fixes for eight PoC variants) indicates sophisticated evasion potential and defense difficulty. EPSS data unavailable, but the combination of trivial exploitation, widespread deployment in security-sensitive contexts (plugin systems, online code evaluators, serverless function platforms), and public PoC code makes active exploitation highly probable. Patch adoption is mandatory; no compensating controls exist for a sandbox escape vulnerability - the entire security model depends on the boundary vm2 failed to maintain.

An attacker submits malicious JavaScript code to a web application's plugin system or online code evaluator that uses vm2 for sandboxing. The payload constructs a crafted object combining Buffer.prototype.slice/inspect/hexSlice with a custom stylize callback, then invokes inspect with showProxy:true. The stylize callback harvests the leaked proxy handler from this.seen[1], uses the handler's fromOtherWithContext method to reconstruct a host-realm Function constructor, and executes arbitrary system commands (process spawning, file system access, network connections) with full privileges of the Node.js process. Eight distinct exploitation primitives (objectWrapper write-back, fromOtherWithContext, doPreventExtensions property forgery, getFactory constructor access, direct trap calls, reduce-bind chains, and two handler-class-reconstruction variants) provide redundant attack paths, making automated exploitation trivial. Public PoC code in GHSA-v37h-5mfm-c47c and repository test suite (test/ghsa/GHSA-v37h-5mfm-c47c/harvest-history.js) demonstrates complete sandbox escape extracting process.pid, trivially adapted to reverse shell or data exfiltration payloads.