vm2 EUVD-2026-81608

Requires an application that (1) uses vm2 before the patched release, (2) sets allowAsync:false in VM or NodeVM and relies on it as a security control, and (3) executes attacker-controlled JavaScript inside the sandbox. The attacker must be able to supply sandboxed script that calls a Promise static method (Promise.resolve/all/race/any/allSettled) with an attacker-defined thenable. Exploitation is limited to deployments that treat the sandbox and its timeout/async restriction as a trust boundary; applications that already permit async or do not run untrusted code are unaffected. No user interaction beyond submitting the script; PR:L reflects the assumed ability to run code in the sandbox.

This is a genuine but moderate-severity protection-mechanism failure (CWE-693), not a high-priority emergency. The vendor CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:L/VA:H, base 7.1) is availability-dominant: the flaw defeats the allowAsync:false control and the run() timeout, letting sandboxed work continue after the host thinks execution finished (VA:H), with only minor integrity impact (VI:L) and no confidentiality impact (VC:N). Crucially, every vm2 vulnerability is gated on the application's core threat model - the host must be executing untrusted/attacker-supplied JavaScript inside the sandbox, which is reflected in PR:L rather than PR:N. No EPSS score, no CISA KEV listing, and no standalone proof-of-concept are present in the input: exploitation status is 'no public exploit identified at time of analysis.' The VC:N in the vendor vector directly conflicts with the input 'Information Disclosure' tag - the described impact is asynchronous execution escaping the timeout, not data disclosure, so that tag appears mislabeled. Overall this is a real correctness/isolation weakness for anyone relying on allowAsync:false as a security boundary, but with no active exploitation signal and availability-only impact, it is a patch-in-normal-cycle item rather than a fire drill.

An application embeds vm2 with allowAsync:false and a timeout, trusting that untrusted script cannot run asynchronous or post-timeout work. An attacker submits sandboxed JavaScript that hands a crafted thenable to Promise.resolve/all/race/any/allSettled; native promise resolution assimilates it and invokes the sandbox's then in a later microtask, bypassing the patched then, so the attacker's code keeps running after run() returns and outside the timeout. No public exploit code is identified in the provided data.