vm2 CVE-2026-44001

No special conditions - remote unauthenticated exploitation against default configurations of vm2 versions <= 3.10.5 running on Node.js 15+ (which terminates processes on unhandled rejections by default). The vulnerability is triggered by executing any sandboxed code that creates a Promise constructor with the specific executor logic (Error object with Symbol name, then stack access). The CVSS vector AV:N/AC:L/PR:N/UI:N indicates network-accessible attack vector with low complexity, no required privileges, and no user interaction. The vulnerability affects ALL vm2 configurations including those using the allowAsync: false hardening option - in fact, allowAsync: false makes exploitation guaranteed because it blocks .catch() method calls while leaving the Promise constructor accessible, ensuring all executor rejections are unhandled. Limiting factors are minimal: attackers need only the ability to submit arbitrary JavaScript code to a vm2 execution endpoint, which is the core use case for applications using this library. The vulnerability works across all platforms (Linux, Windows, macOS) running Node.js >= 15, and also affects Node.js 14 and earlier if the application explicitly sets --unhandled-rejections=strict or uses frameworks that configure this behavior.

Real-world risk is HIGH despite moderate CVSS 8.6. The CVSS vector (AV:N/AC:L/PR:N/UI:N/S:C) correctly indicates remote unauthenticated exploitation with low complexity and scope change (sandbox escape to host process). Publicly available exploit code exists in GitHub advisory GHSA-hw58-p9xv-2mjh with working PoC requiring only 3 lines of sandboxed code. The vulnerability affects ALL vm2 deployments <= 3.10.5 regardless of configuration - the allowAsync: false mitigation recommended for other sandbox escapes actively worsens this issue. Amplification ratio is extreme: a single 150-byte HTTP request terminates processes serving thousands of concurrent users. Testing confirms persistent DoS even with Docker restart policies, Kubernetes liveness probes, and PM2 auto-restart - attackers can re-crash the process before it recovers, creating continuous denial-of-service loops. Unlike many high-CVSS theoretical vulnerabilities, this has immediate operational impact on production web services, API gateways, serverless functions, and any Node.js application executing user-provided code via vm2. The scope change to 'C' (Changed) in CVSS is justified - the vulnerability breaks out of the sandbox isolation boundary to impact the host process. Primary risk is availability (process crash), but the broader implication is that vm2's core security promise (safe untrusted code execution) is broken. GitHub advisory context shows this is one of 13 sandbox escapes patched in v3.11.0, several achieving full RCE, indicating systemic architectural weaknesses in the library's isolation model.

An attacker identifies a public-facing API endpoint at https://target.com/api/execute that accepts JSON payloads with user-provided JavaScript code for execution via vm2 (common in code playground platforms, webhook processors, or low-code automation tools). The attacker sends a single HTTP POST request with a 150-byte JSON payload containing the exploit code: {"code":"new Promise(function(r,j){var e=new Error();e.name=Symbol();e.stack})"}. The vm2 sandbox executes the code, creating a Promise whose executor triggers a V8 internal error when accessing the .stack property of an Error object with a Symbol name. This host-realm TypeError becomes an unhandled rejection that propagates outside the sandbox, crashing the entire Node.js process (confirmed by process exit code 1). All concurrent users - potentially thousands on a single web server - immediately lose service. The attacker can script repeated requests to crash the process again after each automatic restart (Docker, Kubernetes, PM2), creating a continuous denial-of-service loop with negligible cost (bandwidth for a few hundred bytes per minute) while legitimate users never regain access.