Critical SandboxJS Escape Vulnerability Allows Host Takeover

A critical security flaw has been discovered in SandboxJS, a widely adopted JavaScript sandboxing library available on npm. This vulnerability enables attackers to completely break out of the sandbox environment, allowing them to execute arbitrary code directly on the host system.

Tracked as CVE-2026-43898, it carries a maximum severity score of 10.0, which is as serious as a security vulnerability can possibly get in today’s increasingly hostile global threat landscape.

The flaw affects all versions of the @nyariv/sandboxjs package up to and including version 0.9.5. At its core, the problem is that sandbox-defined functions were accidentally leaking a powerful internal callback called LispType.Call.

Once an attacker gets hold of that callback, they can use it to reach outside the sandbox and take full, unrestricted control of the entire underlying host environment.

Security researchers at GitHub identified the flaw and published the advisory under the identifier GHSA-g8f2-4f4f-5jqw. The vulnerability was reported by a security researcher known as Macabely, who also provided a working proof-of-concept to demonstrate exactly how the escape could be carried out under real-world conditions.

The impact is severe, since an attacker exploiting this flaw can achieve full remote code execution on the host machine, with no login credentials required and no need for any user interaction whatsoever. That means any application using the affected library to run untrusted JavaScript is potentially at risk of complete and total host takeover.

How the Sandbox Escape Works?

A patched version, 0.9.6, has been released and is now available on npm. All users of the affected package are strongly advised to update immediately. Staying on any version at or below 0.9.5 leaves the door wide open for this type of devastating attack.

The vulnerability lives in the property access logic inside a file called prop.ts, specifically in a function called addOps. The issue is that sandboxed code was allowed to read the caller, callee, and arguments properties on functions.

In the CommonJS build of the library, this made it possible for a sandboxed function to call something like function f(){ return f.caller } and receive back the internal host-side callback that originally triggered it.

That leaked callback is the LispType.Call operation, which handles function calls inside the runtime. The critical problem is that this handler accepts a params object and uses its fields directly, without checking whether those fields actually came from the trusted executor.

Since the attacker fully controls those fields, they can craft forged input that tricks the handler into doing things it was never meant to do.

By chaining a series of crafted calls through the leaked callback, an attacker can extract the real host Function constructor. Once they have that, they can pass it a string of JavaScript code and execute it directly on the host.

The proof-of-concept included in the advisory demonstrates this clearly by running a system command through Node’s built-in child_process module.

Remote Code Execution and the Broader Risk

The CVSS score of 10.0 reflects just how dangerous this vulnerability truly is. The attack can be launched over the network, requires low complexity to pull off, needs no special privileges, and does not rely on any action from a user.

The scope is marked as Changed, meaning a successful exploit crosses the boundary from the sandbox environment directly into the host system.

Any platform that uses SandboxJS to execute user-submitted or third-party JavaScript is in the line of fire. This includes online code editors, server-side scripting tools, automation platforms, and any application that processes untrusted scripts.

Once the sandbox is broken, attackers gain full access to the confidentiality, integrity, and availability of the host.

The fix in version 0.9.6 addresses the root cause by blocking access to the caller, callee, and arguments properties within sandboxed code.

Developers who cannot update right away should avoid running any untrusted JavaScript through the affected library until the patch has been properly applied and thoroughly tested in their own environment.

Disclaimer: HackersRadar reports on cybersecurity threats and incidents for informational and awareness purposes only. We do not engage in hacking activities, data exfiltration, or the hosting or distribution of stolen or leaked information. All content is based on publicly available sources.