Critical SandboxJS Escape Flaw Allows Host Code Execution in Affected Apps

A critical vulnerability in SandboxJS can allow attacker-controlled JavaScript to escape the sandbox and execute code on the host system. The flaw is tracked as CVE-2026-43898 and affects the npm package @nyariv/sandboxjs up to and including version 0.9.5.

The issue has a CVSS 3.1 score of 10.0, the highest possible rating. GitHub’s advisory says the flaw allows sandboxed code to recover an internal runtime callback, use forged values, reach the real host Function constructor, and run arbitrary JavaScript outside the sandbox.

Applications face the most risk if they use SandboxJS to execute untrusted or user-submitted JavaScript. That includes online code tools, automation platforms, server-side scripting features, plugin systems, and any product that relies on SandboxJS as a security boundary.

What CVE-2026-43898 affects

CVE-2026-43898 affects @nyariv/sandboxjs, a JavaScript sandboxing library available through npm. The vulnerable versions include all releases before 0.9.6.

The patched version is 0.9.6. Developers using the library should update immediately and review whether any untrusted JavaScript ran through affected versions before the patch was applied.

GitHub published the advisory under GHSA-g8f2-4f4f-5jqw. The vulnerability was reported by researcher Macabely and is classified under CWE-94, improper control of code generation.

Item	Details
CVE	CVE-2026-43898
GitHub advisory	GHSA-g8f2-4f4f-5jqw
Package	@nyariv/sandboxjs
Affected versions	All versions before 0.9.6
Patched version	0.9.6
Severity	Critical, CVSS 10.0
Weakness	CWE-94 code injection
Main impact	Sandbox escape leading to host code execution

How the SandboxJS escape works

The vulnerability sits in the property access logic registered through addOps in prop.ts. Affected versions allowed sandboxed code to access sensitive function properties such as caller, callee, and arguments.

In the CommonJS build, this behavior allowed sandboxed code to read Function.caller and leak a privileged internal callback named LispType.Call. That callback normally belongs to the SandboxJS runtime and should not be available to untrusted code.

Once leaked, the callback could be invoked with attacker-controlled fake context and object values. This gave the attacker a path to recover blocked host statics and ultimately reach the host Function constructor.

Why the host Function constructor matters

The host Function constructor is dangerous in this context because it lets JavaScript code create and run new code in the host environment. If a sandboxed script can reach it, the sandbox no longer provides meaningful isolation.

The proof of concept in the GitHub advisory demonstrates the risk by executing a system command through Node.js built-in functionality. That shows the attack can move from sandboxed JavaScript to host-level command execution inside the application process.

The exact impact depends on how the vulnerable application runs. If the Node.js process has access to files, environment variables, cloud credentials, internal APIs, or database connections, a successful attacker may also gain access to those resources.

• Attackers can escape the SandboxJS boundary.
• Malicious scripts can execute JavaScript in the host process.
• Applications that run user-submitted code face the highest risk.
• Secrets available to the host process may be exposed.
• Attackers may modify data or disrupt service depending on process permissions.

Why the CVSS score is 10.0

The advisory gives CVE-2026-43898 a CVSS vector of AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H. That means exploitation can happen over a network in vulnerable application designs, requires low attack complexity, needs no privileges, and requires no user interaction.

The scope is marked as changed because exploitation crosses the intended boundary between sandboxed code and the host environment. The confidentiality, integrity, and availability impact ratings are all high.

This does not mean the npm package attacks systems automatically after installation. It means any application that exposes the vulnerable sandbox to attacker-controlled JavaScript can become a path to full host-process code execution.

CVSS factor	Meaning for this flaw
Attack vector: Network	A vulnerable service may receive malicious JavaScript remotely.
Attack complexity: Low	The advisory includes a working proof-of-concept path.
Privileges required: None	The attacker does not need an existing account in affected exposure scenarios.
User interaction: None	The attack can run when the vulnerable service processes malicious input.
Scope: Changed	The exploit crosses from sandboxed code into the host runtime.

Which applications face the highest risk

The highest-risk applications are those that treat SandboxJS as a security boundary for untrusted JavaScript. This includes services where users can submit scripts, formulas, plugins, automations, templates, or code snippets.

Internal tools can also be exposed. A workflow automation platform, admin panel, testing system, or developer utility may still become a serious risk if a lower-privileged user can submit JavaScript that runs through SandboxJS.

Public-facing services should receive the fastest attention. If unauthenticated users can provide JavaScript to a vulnerable SandboxJS runtime, the application may be exposed to remote code execution without credentials.

What developers should do now

Developers should upgrade @nyariv/sandboxjs to version 0.9.6 or later. Teams should also rebuild deployments, refresh lockfiles, and confirm that production systems no longer load vulnerable versions.

Updating the package is the first step, but teams should also review logs for suspicious script execution. Any system that processed untrusted JavaScript through affected versions should be treated as potentially exposed.

If the vulnerable application handled secrets, environment variables, API tokens, cloud credentials, database passwords, or user data, teams should review whether those secrets were accessible to the Node.js process and rotate sensitive credentials where appropriate.

1. Check package.json and lockfiles for @nyariv/sandboxjs.
2. Upgrade the package to version 0.9.6 or later.
3. Rebuild and redeploy affected applications.
4. Search logs for suspicious submitted JavaScript or unexpected child process execution.
5. Review whether the host process had access to sensitive credentials.
6. Rotate exposed secrets if exploitation cannot be ruled out.
7. Temporarily disable untrusted script execution if patching cannot happen immediately.

Temporary risk reduction if immediate patching is delayed

Developers who cannot update immediately should stop running untrusted JavaScript through affected SandboxJS versions. This is the safest temporary action because the flaw breaks the library’s core isolation promise.

Teams should also reduce the privileges of the process that hosts the sandbox. The process should not run as root or administrator, and it should not have broad filesystem, network, or credential access.

Sandboxing libraries should sit inside layered controls. A JavaScript sandbox should not be the only barrier between untrusted code and sensitive infrastructure.

• Disable public script execution until the patch is deployed.
• Run the service with the lowest possible privileges.
• Move execution into a separate container or isolated worker.
• Restrict outbound network access from the sandbox host.
• Remove unnecessary environment variables and secrets from the process.
• Apply monitoring for child_process, process access, and unusual command execution.

Why this is a reminder about JavaScript sandboxing risk

JavaScript sandboxing is difficult because the language contains many reflective and dynamic features. Small exposure mistakes can create paths from restricted code into host objects, constructors, prototypes, or internal callbacks.

SandboxJS has also had several earlier sandbox escape advisories in 2026. That history does not mean developers must avoid every sandbox library, but it does show why teams should avoid relying on one library as their only security boundary.

For high-risk workloads, safer designs isolate untrusted execution at the operating system or container level. That way, a JavaScript sandbox escape does not immediately become broad host compromise.

FAQ