vm2 CVE-2026-44008

Requires that the target application uses vm2 package version 3.11.1 or earlier AND accepts attacker-controlled JavaScript code for execution inside the vm2 sandbox. The vulnerability is exploitable against default vm2 configurations with no special features or settings required - the flaw is in the core neutralizeArraySpeciesBatch isolation mechanism. Exploitation is limited by the application's trust boundary: if the application only executes internally-authored scripts via vm2 (not user-supplied code), the vulnerability is not exploitable through external attackers. However, any scenario where untrusted code reaches vm.run() enables remote unauthenticated code execution against the host system. CVSS vector AV:N/AC:L/PR:N/UI:N reflects that no user interaction, authentication, or complex setup is needed once attacker-controlled code enters the sandbox - the POC demonstrates exploitation in under 10 lines with no advanced techniques required.

CVSS 9.8 (AV:N/AC:L/PR:N/UI:N) reflects the technical severity but requires context to assess real-world priority. The 'network vector' rating assumes vm2 is deployed in a network-facing service that accepts untrusted code (e.g., online code playgrounds, serverless function platforms, educational coding tools). In such deployments, this is a critical complete-compromise vulnerability. However, exploitation prerequisites are specific: the application must (1) use vm2 ≤3.11.1, (2) execute attacker-controlled JavaScript code within the sandbox, and (3) grant that code control over what gets executed (not just data processing). The publicly available POC (from GitHub Security Advisory GHSA-9qj6-qjgg-37qq) demonstrates trivial exploitation - the code is 9 lines and requires no special techniques beyond basic JavaScript knowledge. EPSS and KEV data not provided, but the ease of exploitation, public POC, and vm2's popularity in Node.js sandboxing suggest likelihood of active exploitation in affected deployments. Notably, vm2 v3.11.2 fixes three concurrent sandbox escapes (GHSA-9qj6-qjgg-37qq, GHSA-9vg3-4rfj-wgcm, GHSA-2cm2-m3w5-gp2f), indicating vm2's sandbox model had systemic weaknesses in its 3.11.1 state. Priority depends on deployment context: critical for untrusted-code-execution platforms, lower for applications using vm2 for internal scripting of trusted code only.

An attacker targeting an online JavaScript coding playground built with vm2 ≤3.11.1 submits the 9-line POC code through the web interface. When the server executes this code inside the vm2 sandbox (believing it to be safely isolated), the malicious setter on Array.prototype[0] triggers during Buffer allocation, chains through constructor properties to access the Node.js process object, and executes 'child_process.execSync' to run arbitrary shell commands (e.g., installing a reverse shell, exfiltrating environment variables containing API keys, or pivoting to internal infrastructure). Since the CVSS vector shows PR:N (no privileges required), the attacker needs no authentication beyond whatever access the application grants to submit code snippets. The publicly available POC makes this trivial to exploit.