CVE-2026-34208 is a critical (CVSS 10.0) bypass in SandboxJS, a JavaScript sandboxing library. Sandboxed code can write to host global objects and the change persists across sandbox instances. The fix is version 0.8.36, so upgrade the sandboxjs npm package. Restart long-running processes afterward.
What's affected
The project's advisory (GHSA-2gg9-6p7w-6cpj) lists sandboxjs 0.8.35 as affected and 0.8.36 as patched. The NVD record states versions prior to 0.8.36.
The library is meant to run untrusted JavaScript safely. It blocks direct assignment to global objects, for example overwriting Math.random. The advisory says that block can be bypassed through a callable constructor path that is exposed to the sandboxed code, because the library's internal global function is reachable and Function.prototype.call is allowed.
The effect is that sandboxed code can write properties into host global objects, and those changes persist across sandbox instances in the same process.
How to check if you're exposed
Find the version in your tree:
npm ls sandboxjs
Check every service and package that uses it, not only the top level, since libraries can bundle it. A lockfile scan helps with that. Paste a lockfile or manifest into the free in-browser dependency scan to see whether the package is in your tree, including as a transitive dependency. Reachability analysis then helps you judge whether your code calls the affected path, so you can order the work sensibly.
Then think about what runs inside the sandbox. If all the code is your own, the risk is lower. If it comes from users, plugins or templates, the sandbox boundary is your security control, and a bypass reaches the host process.
Search for the package name in lockfiles of every repository, not only the ones you think of as using sandboxes. Plugin systems, template engines and rule engines sometimes bring in a JavaScript sandbox.
What to do now
- Find every service that uses sandboxjs, directly or through another package.
- Upgrade to 0.8.36 or later and run your tests.
- Restart long-running processes so a polluted global state does not survive, since the advisory says changes persist inside the process.
- Audit which parties can submit code that runs in the sandbox, and cut that list down.
- For high-risk cases, run untrusted code in a separate process or container instead of relying on an in-process sandbox alone.
Why it matters
The record lists CWE-693 (protection mechanism failure) and CWE-915 (improperly controlled modification of dynamically determined object attributes). In short, the guard on writes could be sidestepped, and attacker-controlled objects could then change shared state.
Shared state is what makes this serious. A change to a host global does not stay inside the sandbox run that made it. Later runs, including runs for other users, can see the altered behavior. That turns one bad script into a risk for the whole process.
Sandboxes written in the same language they confine face a hard problem, since a single missed path gives scripts a way back to the host. The record does not mark this CVE as exploited, and it is not on the CISA KEV list.
If you depend on this library for untrusted code, add a second layer. Run the host process with the least privilege it needs, keep secrets out of its environment, and prefer a process per tenant over a shared one, so a polluted global cannot cross a trust boundary.
Quick check
Do I need to restart after upgrading?
The advisory says polluted state persists within the process, so restarting after the upgrade is a sensible step.
Sources
Last reviewed: 19 October 2026.
