n8n Sandbox Escape Lets Workflow Editors Run OS Commands as the n8n Process

n8n has patched a high-severity vulnerability that allows an authenticated workflow editor to break out of the platform's JavaScript expression sandbox and execute arbitrary operating-system commands with the privileges of the n8n process. The flaw was discovered by Security Joes while auditing n8n's February 2026 fix for a prior sandbox escape (CVE-2026-27577).

Advisory Details

What Went Wrong: Two Blind Spots in the Sandbox

n8n uses a custom JavaScript sandbox to safely evaluate expressions written by workflow editors. The February 2026 patch for CVE-2026-27577 closed one bypass, but left two independent gaps that Security Joes chained into a new escape:

1. Arrow Function Blind Spot

In n8n 2.31.4, ArrowFunctionExpression nodes were placed in a no-op branch of the sandbox's AST evaluator. This meant that concise arrow function bodies—like () => process—were resolved against real Node.js globals instead of the sandboxed equivalents. An attacker could use a simple arrow function to obtain a reference to the global process object.

2. Dynamic Property Access via Reflect.get

Even when the sandbox blocked static property access by name, it did not inspect the arguments passed to functions dynamically. An attacker could call Reflect.get() with dynamic arguments to retrieve process.getBuiltinModule, then use it to load child_process and execute shell commands on the host.

Together, the two bypasses gave an attacker a clean path from "expression in a workflow node" to "shell command running as the n8n process."

Impact: Full Host Compromise

Successful exploitation gives the attacker:

• Arbitrary OS command execution with n8n process privileges
• Access to N8N_ENCRYPTION_KEY, which decrypts all stored credentials (API keys, database passwords, OAuth tokens, cloud access credentials)
• Full access to all connected services—databases, internal APIs, cloud accounts, and any service reachable from the n8n host

The impact is effectively a full host compromise for any service n8n has credentials for. In enterprise deployments where n8n is connected to dozens of services, the blast radius is substantial.

Prerequisites: A valid n8n account with workflow creation or modification permissions. No further interaction is required.

Timeline

No in-the-wild exploitation has been confirmed as of publication.

Mitigation

Update immediately. Patch to n8n 2.31.5 (on the 2.31.x branch) or n8n 2.32.1 (on the 2.32.x branch). There is no patched release for the 1.x line—users on 1.x must upgrade to a patched version.

Additional defensive steps:

1. Audit workflows for suspicious arrow function expressions or obfuscated JavaScript
2. Monitor for unexpected child processes spawned by n8n or its Node.js parent process
3. Rotate all credentials stored in n8n if you have any reason to suspect unauthorized access
4. Restrict workflow editor access to the minimum number of trusted users
5. Review n8n network egress to detect unusual outbound connections

A Note for Self-Hosted Deployments

Self-hosted n8n instances are disproportionately at risk. Cloud-hosted instances on n8n.cloud were patched server-side. Self-hosted operators who run n8n in Docker or on bare metal must pull the updated image or upgrade the npm package manually.

The credential decryption risk is especially serious for self-hosted deployments where N8N_ENCRYPTION_KEY protects a large number of integration credentials. Treat a delayed patch as a window of exposure—not just a theoretical one.

References

• GHSA-gv7g-jm28-cr3m — n8n security advisory
• CVE-2026-27577 — the February 2026 predecessor flaw
• Security Joes disclosure report
• The Hacker News, July 27, 2026