CVE-2026-92942: vm2: timeout Option Bypass via FinalizationRegistry Cleanup Callback (Unbounded Host Event-Loop Block)

vm2’s VM({ timeout }) option is documented and relied upon as the mechanism that bounds how long sandboxed code may execute. In the current implementation, the timeout only wraps the single synchronous call to VM#run() (via doWithTimeout → this._runScript(script) in lib/vm.js). It does not, and structurally cannot, bound code that the V8 engine itself schedules to run after that call has already returned.

FinalizationRegistry and WeakRef are exposed to sandboxed code completely unmodified — they are not present anywhere in lib/setup-sandbox.js’s list of specially-wrapped/hardened globals (only WeakMap, Promise, Proxy, Reflect, etc. receive hardening there). Sandboxed code can register a FinalizationRegistry callback against an object it creates and immediately drops. VM#run() returns normally, well within the configured timeout, because registration is instant. At some later point — determined entirely by the V8 garbage collector, and forceable on demand by the host process (e.g. under memory pressure, or via --expose-gc) — the engine invokes the sandboxed cleanup callback directly. This invocation is not mediated by doWithTimeout, Script.runInContext({timeout}), or any other vm2 accounting mechanism, because it isn’t a new call to VM#run() at all — it’s the GC’s own native callback-invocation path.