Dirty Laundry: Escaping SandboxJS via Array Laundering

JavaScript sandboxing is like trying to hold water in a sieve. The language is so dynamic, so mutable, and so interconnected that creating a truly isolated environment is a Herculean task. @nyariv/sandboxjs attempts this by parsing and executing JS in a controlled scope, wrapping objects to track permissions. The goal is simple: let users run untrusted code without burning down the server.

However, the library relies on a concept called 'taint tracking'—specifically, an isGlobal flag attached to wrappers around sensitive host objects (like window, process, or Array.prototype). If isGlobal is true, the sandbox blocks write access. It's a 'Do Not Touch' sticker on the museum exhibits.

The problem with stickers is that they fall off if you handle the merchandise too much. In CVE-2026-25881, we found a way to peel that sticker off simply by putting the object in a box and taking it back out.

The vulnerability lies in how the sandbox handles intermediate values, specifically Array Literals. When the sandbox executes code, it wraps every object in a Prop class. This class holds the isGlobal boolean. If you try to access Array.prototype directly, the sandbox hands you a wrapper with isGlobal: true.

Here is where the logic breaks down. When you define an array literal like [Array.prototype], the sandbox's CreateArray operation extracts the raw value from the wrapper to populate the new array. It effectively says, 'Okay, you want an array containing this object? Here is the object.' It forgets to attach the 'Do Not Touch' note to the array's internal storage of that object.

When you subsequently access that index (e.g., arr[0]), the sandbox creates a new wrapper for the retrieved value. Since the retrieval didn't come from a known global lookup (it just came from some random array), the new wrapper defaults to isGlobal: false. The object has been 'laundered'. It is now a clean, writable reference to the host's actual Array.prototype.

The root cause was a philosophical error in the code: trusting the path of access rather than the identity of the object. The fix introduced in version 0.8.31 completely shifts this paradigm.

The Vulnerable Logic (Conceptual):

// Old way: Relying on metadata passing
function getProperty(obj, key) {
  const value = obj[key];
  // If obj was a random array, we assume 'value' is safe.
  return new Prop(value, { isGlobal: false }); 
}

The Fix (Identity Check): The patch introduces a helper getGlobalProp that runs on every property access. It checks the value itself against a list of known dangerous globals.

// src/executor.ts
function getGlobalProp(val: unknown, context: IExecContext, prop?: Prop) {
  if (!val) return;
  
  // CRITICAL: Check if the value IS the global object
  if (val === globalThis) {
    return new Prop({ [p]: context.ctx.sandboxGlobal }, p, prop?.isConst, false, prop?.isVariable);
  }
 
  // Check if value is a known host function or prototype
  const e = isFunc && context.evals.get(val);
  if (e) {
    // FORCE the protection flag back on
    return new Prop({ [p]: e }, p, prop?.isConst, true, prop?.isVariable);
  }
}

By validating the identity of val against the context's allowlist (context.evals), the sandbox re-applies the handcuffs even if the object was laundered through a dozen arrays.

Exploiting this is embarrassingly simple. We don't need complex heap manipulation or race conditions. We just need to move an object from Point A to Point B.

The Attack Chain:

1. Target Acquisition: We need a reference to a host prototype. Array.prototype is perfect because it's available everywhere.
2. The Wash Cycle: We wrap it in an array literal.
3. The Rinse: We read it back out. The sandbox sees this as "just an item from a user array" and grants us a writable wrapper.
4. Pollution: We write to the prototype. Because JS is prototype-based, this modifies the Array definition for the entire host process.

The PoC:

// Inside the sandbox
const laundryBasket = [Array.prototype]; 
const cleanShirt = laundryBasket[0]; // The 'isGlobal' flag is gone now
 
// Add a property to the actual host Array prototype
cleanShirt.polluted = "I am in your walls";
 
// Verification (in Host)
// console.log([].polluted) -> "I am in your walls"

If the host application later runs code like const cmd = userOptions.cmd || 'default', and we've polluted Object.prototype to inject a malicious command, we achieve Remote Code Execution.

Why is this rated Critical (9.1)? Because SandboxJS is often used to run user-submitted scripts in SaaS platforms, rule engines, or plugin systems. Breaking out of the sandbox destroys the security model entirely.

Once an attacker has Prototype Pollution on the host, they can usually escalate to RCE. Common patterns include:

• Template Injection: Polluting properties used by template engines (e.g., outputFunctionName in EJS).
• Process Spawning: Polluting shell or env options passed to child_process.exec or spawn.
• DoS: Overwriting toString or valueOf to throw errors or enter infinite loops.

This isn't just a data leak; it's full server compromise if the host application uses any standard libraries vulnerable to pollution gadgets.

The remediation is straightforward: Update to version 0.8.31.

The patch forces the sandbox to be paranoid. It no longer trusts that a value is safe just because it came from a safe place. It checks the ID card of every object, every time it is accessed.

If you cannot update immediately, you are essentially running code on the host with extra steps. A temporary mitigation (though ugly) would be to freeze all prototypes in the host environment before starting the sandbox:

// Host-side mitigation
Object.freeze(Object.prototype);
Object.freeze(Array.prototype);
// ... repeat for all built-ins

This might break other dependencies, but it stops the bleeding until you can patch.