SandboxJS Vulnerability Enables Host JavaScript Escape

A newly disclosed SandboxJS vulnerability has exposed a critical sandbox escape mechanism that could allow attackers to execute arbitrary JavaScript code on the host environment.

The flaw affects the popular @nyariv/sandboxjs package and stems from improper isolation between sandboxed code and privileged internal runtime operations. Security researchers demonstrated that attackers could abuse exposed JavaScript function internals to recover restricted runtime callbacks and fully bypass sandbox protections.

The vulnerability effectively enables hostile code running inside the sandbox to escape containment and execute commands directly on the underlying host system.

How the SandboxJS Vulnerability Works

The issue originates from the way SandboxJS handles property access for sandbox-defined functions.

Researchers discovered that sandboxed functions could still access sensitive JavaScript properties including:

• Function.caller
• callee
• arguments

Under normal secure sandbox conditions, these properties should not expose privileged runtime internals. However, the implementation allowed sandboxed code to leak a protected internal callback known as LispType.Call.

That callback is responsible for executing internal runtime operations inside SandboxJS.

By recovering this privileged function, attackers could forge execution contexts and manipulate internal objects that were never intended to be exposed to untrusted code.

Sandbox Escape Leads to Host Access

The exploit becomes especially dangerous because the internal runtime callback fails to validate attacker-controlled parameters before processing them.

Researchers found that malicious code could manipulate several internal fields, including:

• obj.context
• obj.prop
• obj.get
• context.evals.get

Using forged runtime objects, attackers were able to:

• Extract blocked host static methods
• Recover the real host Function constructor
• Execute arbitrary JavaScript outside the sandbox
• Access sensitive host-level functionality

The proof-of-concept exploit ultimately demonstrated command execution on the host machine using Node.js process access.

In the published demonstration, the payload invoked:

process.getBuiltinModule("child_process")
.execSync("whoami")
.toString()

This command confirmed successful sandbox escape and direct operating system interaction.

Why Function.caller Became the Weak Link

The vulnerability highlights the long-standing security risks associated with reflective JavaScript properties such as Function.caller.

SandboxJS internally created standard host JavaScript functions during execution. Because these functions behaved like normal host-side objects, sandboxed code could inspect the call chain and retrieve privileged execution callbacks.

This created an unintended bridge between untrusted sandbox code and trusted runtime internals.

Security researchers noted that the flaw was not caused by a single unsafe API alone, but by the combination of:

• Exposed reflective properties
• Insecure internal callback handling
• Missing runtime validation
• Overly trusted execution contexts

Potential Impact on Applications

The SandboxJS vulnerability poses significant risks for applications relying on the library to safely execute untrusted JavaScript code.

Affected environments may include:

• Online code runners
• Server-side JavaScript execution platforms
• Educational coding sandboxes
• Automation tools
• Plugin ecosystems
• AI-generated code execution systems

Successful exploitation could allow attackers to completely bypass sandbox restrictions and gain access to the host runtime.

Depending on deployment configuration, this may lead to:

• Remote code execution
• Server compromise
• Data theft
• Container escape scenarios
• Supply chain attacks

Security Recommendations

Developers and administrators using SandboxJS should immediately review exposed environments and restrict execution of untrusted code until patched versions become available.

Security teams are advised to:

• Audit applications using @nyariv/sandboxjs
• Disable untrusted runtime execution where possible
• Monitor for suspicious child process activity
• Restrict Node.js privileged module access
• Isolate sandbox environments using OS-level protections

The latest SandboxJS vulnerability serves as another reminder that JavaScript sandboxing remains an extremely difficult security challenge, particularly when reflective language features and internal runtime callbacks intersect with untrusted code execution.