VM2 CVE-2026-24118

The attacker must be able to execute arbitrary JavaScript code within a VM2 sandbox context. This requires the application to accept user-supplied JavaScript and execute it using the VM2 library, which is the intended use case for VM2 in scenarios like online code editors, plugin systems, serverless function runtimes, or educational coding platforms. No special VM2 configuration is required - default VM2 sandbox instantiation via new VM() is sufficient. The vulnerability affects VM2 in its standard operating mode, not an edge-case configuration. Limiting factors: The attacker needs a code path where their JavaScript reaches VM2 execution (applications using VM2 only for trusted internal code are not exposed). The exploit requires Node.js runtime with Buffer object access, which is standard in VM2 environments. Network-level access is not a prerequisite - the attack occurs at the application logic layer once the attacker can submit code through the application's intended interface (web form, API endpoint, file upload, etc.).

This represents critical real-world risk confirmed by multiple strong signals. CVSS 9.8 with vector AV:N/AC:L/PR:N/UI:N indicates network-accessible, low-complexity exploitation requiring no privileges or interaction - attackers need only the ability to submit code to a VM2 sandbox. Publicly available exploit code exists (GitHub Gist and vendor advisory PoC), significantly lowering the barrier to exploitation. The vulnerability is a complete sandbox escape, the worst possible outcome for an isolation technology. Applications using VM2 to execute untrusted user code (such as online code playgrounds, serverless function platforms, plugin systems, or code evaluation APIs) are immediately vulnerable to full host compromise. The straightforward exploit chain (7-8 lines of JavaScript) means exploitation can be automated. However, the scope is limited to environments where attackers can inject arbitrary JavaScript into VM2 contexts - this is not exploitable against applications merely using VM2 internally with trusted code. Real-world impact depends entirely on whether the application's threat model includes untrusted code execution, but for those that do, this is an immediate patch-now priority. The availability of working PoCs and the fundamental nature of the bypass (circumventing the core security promise of the library) make this high-severity in practice despite absence from CISA KEV.

An attacker submits JavaScript code to a web application's code execution API that uses VM2 for sandboxing, such as an online code playground or a serverless function platform. The attacker's payload uses Buffer.apply to access the host's apply method, chains it with __lookupGetter__ to traverse to the host Function.prototype via Buffer's __proto__, then uses Object.getOwnPropertyDescriptor to extract the host Function constructor despite VM2's attempted blocks. With the host Function constructor, the attacker executes process.mainModule.require('child_process').execSync() to run arbitrary shell commands, exfiltrate environment variables containing API keys, establish reverse shells, or pivot to other systems on the internal network. The publicly available PoC demonstrates the complete exploit chain in under 10 lines of JavaScript.