CVE-2026-92942: vm2 before 3.11.7 Timeout Bypass via FinalizationRegistry

Published Sep 17, 2026
·
Updated

vm2 before 3.11.7 (affected versions <= 3.11.6) does not enforce the VM({ timeout }) option on code executed outside the synchronous VM#run() call. The timeout only wraps the single call to runScript() via doWithTimeout() in lib/vm.js, and FinalizationRegistry and WeakRef are exposed to sandboxed code unmodified (they are not among the hardened globals in lib/setup-sandbox.js). Sandboxed code can register a FinalizationRegistry cleanup callback against an object and then drop the only strong reference to it; vm.run() returns within the configured timeout, but when the V8 garbage collector later reclaims the object it invokes the sandboxed cleanup callback outside any vm2 timeout accounting. A busy loop in that callback blocks the host event loop for an unbounded period, resulting in denial of service. The time of invocation depends on the garbage collector (e.g. under memory pressure or with --expose-gc).

Affected Software

1 affected component
npm/vm2<=3.11.6

Remediation

Recommended actions to resolve this vulnerability, in priority order.

  1. Upgrade

    Upgrade vm2 to a version that resolves this vulnerability.

    Fixed in 3.11.7
  2. Compensating control

    Mitigate the timeout-bypass denial of service by not running untrusted code that can use FinalizationRegistry/WeakRef for cleanup callbacks outside vm2’s synchronous VM#run() timeout accounting.

Event History

Sep 17, 2026
CVE Published
via MITRE·01:46 PM
Data Sourced
via MITRE·01:46 PM
DescriptionSeverityWeakness

Frequently Asked Questions

1

Which deployments are exposed to denial of service?

Deployments using npm/vm2 version 3.11.6 or earlier are affected when sandboxed code can use FinalizationRegistry or WeakRef. The impact is a host event-loop block caused by code running after VM#run() has returned.

2

What does an attacker need to exploit this?

An attacker needs the ability to execute JavaScript in the vm2 sandbox. They can register a FinalizationRegistry cleanup callback, release the registered object, and place a busy loop in the callback; garbage collection later invokes it outside the configured timeout.

3

How can I determine whether timeout protections can be bypassed in my environment?

Check whether your application uses vm2 3.11.6 or earlier and relies on VM({ timeout }) to limit sandbox execution. If sandboxed code can access the default exposed FinalizationRegistry and WeakRef globals, the timeout does not cover cleanup callbacks triggered by garbage collection.

4

What should be done to remediate this issue?

Update vm2 to version 3.11.7 or later. Until updating, do not rely on VM({ timeout }) as a complete execution limit for sandbox code that can use FinalizationRegistry or WeakRef.

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203