On July 22, 2026, n8n shipped versions 2.31.5 and 2.32.1 to fix a high-severity sandbox escape — the second one this year. The vulnerability, tracked as GHSA-gv7g-jm28-cr3m and rated CVSS 8.7, lets anyone with a workflow-editing account break out of n8n's expression sandbox and run arbitrary operating system commands on the server. If you self-host n8n and you're running anything below 2.31.5 (or between 2.32.0 and 2.32.1), you need to update now.

This isn't theoretical. Security Joes found the flaw while testing whether n8n's February fix for CVE-2026-27577 — a 9.4-rated sandbox escape with the same root cause — actually held up. It didn't.

How the escape works

n8n workflows use expressions like ={{ $json.email }} to pull data into nodes. Behind the scenes, an abstract syntax tree rewriter intercepts free JavaScript identifiers in those expressions and redirects them to n8n's controlled data context instead of the real Node.js runtime. That's the sandbox. The idea is that even if someone puts process.env in an expression, the rewriter catches process and replaces it with a safe proxy.

The problem is that the rewriter had two blind spots, and neither one had test coverage.

The first gap was arrow functions. In n8n 2.31.4, the rewriter's VariablePolyfill.ts placed ArrowFunctionExpression in an explicit no-op branch. That means a concise arrow body like () => process would resolve process to the real Node.js global — the actual process object with access to everything the n8n server can do — instead of the sandboxed value. The rewriter simply didn't look inside arrow function bodies.

The second gap was property access. The sandbox's property checks inspect static property names in member expressions. But Reflect.get() passes the requested property as a function argument rather than a static member expression. Security Joes used that distinction to recover process.getBuiltinModule, load child_process, and execute commands on the host.

Neither condition alone was enough. Together, they gave an authenticated user full command execution with the privileges of the n8n process.

What an attacker can actually do

The exploit requires a valid n8n account with permission to create or modify workflows. That's not nothing — it's not an unauthenticated RCE — but in practice, a lot of n8n instances give workflow access broadly. If you've set up n8n for a team and given people editor access so they can build automations, every one of those accounts is an attack surface.

A successful exploit runs commands as the n8n process user. That typically means access to:

  • Stored credentials. n8n encrypts credentials with N8N_ENCRYPTION_KEY, but the key lives on the same server. An attacker who can read the environment or the database can decrypt every OAuth token, API key, and password n8n has stored.
  • Connected services. n8n workflows talk to databases, cloud APIs, internal tools. An attacker with shell access can reach anything n8n can reach.
  • The host itself. Depending on how n8n is deployed — Docker, bare metal, a VM with other services — command execution can mean lateral movement to other applications on the same server.

Security Joes didn't observe exploitation in the wild before the fix, but the proof of concept worked against n8n 2.30.4 through both the released workflow package and a local instance. The technical details are public.

This is a pattern, not a one-off

The February escape (CVE-2026-27577, CVSS 9.4) had the same shape: the AST rewriter missed a code path, and process slipped through untransformed. n8n fixed it, Security Joes checked the fix, and found it was incomplete. The July patch adds a dedicated ArrowFunctionExpression handler that routes bare identifiers in concise arrow bodies through the data context.

This is the kind of vulnerability that keeps recurring in sandboxing layers because the surface area is enormous. JavaScript has dozens of ways to reference the same object — destructuring, computed property access, Reflect, Proxy, with statements, arrow functions, generators. Every time you patch one path, an attacker looks for the next one. n8n's expression sandbox is trying to rewrite arbitrary JavaScript at the AST level, and that's a fundamentally hard problem.

For self-hosters, this means you can't assume a sandbox escape won't happen again. The question isn't whether n8n will patch the next one — they've been responsive — it's whether you'll apply the patch before someone finds it.

What to do right now

Update to 2.31.5 or 2.32.1. If you're on 2.32.0, you need 2.32.1 specifically. There's no patched 1.x release, so if you're still on n8n v1, you need to upgrade.

Audit recent workflows. Look for unexpected arrow functions, obfuscated JavaScript in expression fields, or any expression that references process, require, globalThis, or global. If you find something you didn't create, treat it as compromised.

Rotate credentials. If you find evidence of suspicious workflow execution or unexpected host processes, rotate every credential n8n has stored — API keys, OAuth tokens, database passwords, the lot.

Restrict workflow editing. The exploit requires an account with workflow edit permissions. If you've been giving editor access to everyone on your team because it's convenient, now's a good time to tighten that. Read-only access for people who just need to monitor executions.

Monitor for shell activity. Spawned sh, bash, cmd, powershell, curl, or wget processes as children of the n8n or Node.js process are a red flag.

n8n is a powerful tool, and self-hosting it comes with self-hosting responsibilities. The platform's maintainers are clearly investing in security — two sandbox patches in six months shows active research and responsive disclosure. But the nature of sandboxing JavaScript means this class of bug isn't going away. Stay current, stay patched, and don't give workflow access to people who don't need it.