The vm2 sandbox fails to enforce the allowAsync:false restriction. When the localPromise prototype’s then is patched to throw an error, the static Promise methods still accept attacker‑supplied thenables. The native promise resolution logic calls the sandbox’s then method in a microtask, bypassing the patched handler. As a result, input code can schedule work that executes after VM.run() or NodeVM.run() has returned, and after the configured timeout, allowing the attacker to run code outside the intended sandbox boundaries, effectively escaping the isolation enforced by vm2. This exposes the host to arbitrary code execution in its own process space. The weakness is a CWE‑693 runtime state manipulation issue.

The vulnerability impacts the vm2 npm package produced by patriksimek. All release versions older than 3.11.8 are affected. Projects that instantiate a VM or NodeVM with allowAsync set to false while executing untrusted code are at risk.

The CVSS score of 7.1 indicates a high severity; the EPSS score is not available, and the flaw is not listed in the CISA KEV catalog. Exploitation requires control over the code that is run inside the vm2 sandbox, so the attack is an internal privilege escalation rather than a remote or network‑based vector. An attacker who can supply untrusted JavaScript to a vm2 instance that expects strict async restrictions can inject a thenable, cause a microtask to execute after the sandbox finishes, and run arbitrary code in the host process. Because the vulnerability is purely local and does not involve external network connections, detection depends on observing unexpected asynchronous execution after VM.run returns.