vm2 CVE-2026-92942

Exploitation requires that the host application (1) executes attacker-controlled JavaScript inside a vm2 VM/NodeVM instance and (2) relies on the VM({timeout}) option as its resource-exhaustion control - vm2's intended use case. The attacker uses FinalizationRegistry and WeakRef, which are exposed to the sandbox unmodified because they are not among the hardened globals in lib/setup-sandbox.js. The primary limiting factor is timing controllability: the DoS fires only when V8's garbage collector reclaims the dropped object, which is non-deterministic and depends on host memory pressure (or --expose-gc), so the attacker cannot precisely schedule the disruption. Impact is availability only - no sandbox escape, code execution, or data disclosure. Affects vm2 <= 3.11.6; fixed in 3.11.7.

This is an availability-only denial-of-service (CWE-400) affecting the vm2 sandbox, and its real-world priority is bounded by a hard precondition: the host application must run attacker-controlled JavaScript inside a vm2 instance and rely on VM({timeout}) as a control - vm2's core threat model. The vendor CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:N/UI:N/VA:H, base 8.7) reflects a fully unauthenticated network reach and high availability impact but zero confidentiality/integrity impact, which is consistent with the description - there is no code escape here, only an event-loop block. My independent CVSS 3.1 assessment is ~7.5 (A:H, S:U). No EPSS score, no CISA KEV entry, and no public exploit code are present in the supplied intelligence, so exploitation status is 'no public exploit identified at time of analysis' - do not treat this as actively exploited. One nuance the CVSS vectors understate: the description is explicit that trigger timing depends on the garbage collector (memory pressure or --expose-gc), so the attacker cannot reliably choose WHEN the DoS fires - this argues for AC:H in practice even though the DoS is eventually guaranteed once GC reclaims the object. Net: a genuine but conditional DoS, not a critical remote-compromise issue; it matters only to deployments that hand vm2 untrusted code and depend on the timeout option.

An application uses vm2 with a configured timeout to safely run untrusted user-supplied JavaScript (e.g. a plugin, formula, or code-runner service). The attacker submits code that registers a FinalizationRegistry cleanup callback containing an infinite busy loop against an object, then drops the only strong reference; vm.run() returns cleanly within the timeout, but when V8's garbage collector later reclaims the object it invokes the busy-loop callback outside all vm2 timeout accounting, freezing the host Node.js event loop and denying service to all users. No public proof-of-concept is referenced in the supplied intelligence.