CVE-2026-25641 is a sandbox escape in SandboxJS, the JavaScript sandboxing library, with a CVSS score of 10.0. A mismatch between the property key that is validated and the key that is used lets sandboxed code break out. Versions before 0.8.29 are affected, and 0.8.29 fixes it.
What's affected
- Package: @nyariv/sandboxjs on npm.
- Affected: versions up to and including 0.8.28.
- Fixed: 0.8.29.
- Exposure: applications that run untrusted or user supplied code inside the sandbox, such as plugin, formula or template engines.
How to check if you're exposed
List every copy of the package in your project, including nested ones:
npm ls @nyariv/sandboxjs
yarn why @nyariv/sandboxjs
pnpm why @nyariv/sandboxjs
Then find where the library is called. If nothing you ship passes untrusted code to it, the escape is not reachable from outside, though you should still upgrade.
What to do now
- Upgrade to @nyariv/sandboxjs 0.8.29 or later, and rebuild lockfiles for every service.
- Look for other packages in your tree that bundle SandboxJS and check their release notes.
- Until patched, stop passing untrusted code to the sandbox, or isolate that workload in a separate process or container with no secrets.
- Run the process that hosts the sandbox with the least privileges you can.
- After patching, note that SandboxJS had a second escape (CVE-2026-25881) fixed in 0.8.31, so move to at least that version.
Why it matters
The advisory describes a time of check, time of use mismatch, CWE-367. The key is typed as a string but never enforced, so an attacker can pass an object whose string conversion changes between the safety check and the real property access. The check sees one value and the access uses another.
A sandbox is a promise that hostile code stays inside. When it breaks, whatever the host process can do, the hostile code can do. That is why the score is 10.0 for applications that run untrusted scripts, and why the practical risk depends entirely on whether you do. The record does not mark it as exploited in the wild.
How to prioritise the fix
The first question is whether untrusted code ever enters the sandbox. Libraries like this are used for user defined formulas, automation scripts, template logic and plugin systems. In each of those, the person writing the code may not be someone you employ, and a sandbox escape means their code runs as your server process.
Rank services by what the host process can reach. A sandbox host with database credentials, cloud tokens or access to other tenants' data is a bigger problem than one in an isolated worker. If you cannot patch at once, move the untrusted workload into a container or process with no secrets and a tight network policy, and disable the feature if you can.
Also check the dependency chain. SandboxJS may arrive through another package, in which case your lockfile shows a version you never chose. Use npm ls to see the path, and ask the parent project when it will update. Overrides in your package manager can force 0.8.31 in the meantime, but test them.
A dependency scan answers the first question, which is whether the package is present at all. Reachability analysis answers the second, which is whether your code calls the vulnerable path. You can start with the free scan at gold.safeguard.sh/scan and then read the Gold entry for this CVE to see affected ranges.
Try it yourself
Click through it at your own pace, or open it full screen.
Quick check
Does my app need to be internet facing to be at risk?
The risk comes from attacker controlled code reaching the sandbox, not from the app being public. A plugin or formula field that any user can edit is enough.
Is 0.8.29 the last version I need?
It fixes this CVE. Another escape, CVE-2026-25881, was fixed in 0.8.31, so aim for that or later.
Sources
Last reviewed: 19 October 2026.
