vm2 before version 3.11.6 does not enforce the VM({ timeout }) option on code that runs outside the synchronous VM#run() call. The timeout wrapper only covers the single call to _runScript() and FinalizationRegistry and WeakRef are exposed to sandboxed code unchanged. A sandboxed script can register a cleanup callback with a FinalizationRegistry and then drop the only strong reference to the associated object. When V8 later reclaims the object, the registered callback is invoked outside any vm2 timeout accounting. If that callback contains a busy loop, it blocks the host event loop for an unlimited period, resulting in a denial‑of‑service. It is inferred that the attacker needs the ability to execute arbitrary code within the vm2 sandbox and must have a way to trigger garbage collection, either by allocating large objects or using the --expose‑gc flag.

Vendors affected are those using the patriksimek vm2 package at or below version 3.11.6. The package is updated to 3.11.7 in a release that applies the timeout to all sandboxed code. No other vendors or products are listed in the CVE data.

The CVSS score of 8.7 signals a high‑severity flaw. Because the EPSS score is not available, the probability of exploitation cannot be quantified, but the vulnerability is reported as not listed in CISA KEV. It is inferred that the attacker must be able to execute arbitrary code within the vm2 sandbox and must have the capability to trigger garbage collection. The likely attack path involves an attacker providing malicious code to a vulnerable vm2 instance, registering a cleanup callback that loops indefinitely, and waiting for garbage collection to execute the callback outside the configured timeout, thereby blocking the host process.