# n8n's Sandbox Fix Had a Hole. Researchers Found It.
When n8n shipped a patch for CVE-2026-27577 back in February, the assumption was that the expression sandbox — the layer that's supposed to prevent workflow editors from doing anything too dangerous — was now locked down. It wasn't. Security Joes kept digging and found another way through. The result: an authenticated user with workflow-editor access can pop out of the sandbox and run arbitrary operating-system commands directly on the server hosting the automation platform.
That's not a theoretical risk. That's remote code execution wearing a lab coat.
## What n8n Is, and Why This Is a Bigger Deal Than It Looks
If you're not deep in the self-hosted DevOps world, n8n might not be a name you recognize. Think Zapier or Make — visual workflow automation that connects APIs, databases, triggers, and services. But n8n is open-source and predominantly self-hosted, which means it lives inside company infrastructure, often with direct access to internal APIs, credentials stored as environment variables, database connections, cloud IAM tokens, and whatever else the automation team wired up.
That's the risk profile that makes sandbox escapes here particularly nasty. This isn't a SaaS platform where the blast radius is contained by someone else's isolation layer. When you self-host n8n, the process typically runs with access to everything the hosting account can touch. An attacker who achieves OS-level command execution inherits that access.
The "workflow editor" permission level is also worth unpacking. In mature n8n deployments, this isn't a super-admin role. It's the tier that developers, operations engineers, and sometimes even analysts get. Multi-user deployments — the very reason n8n added permission tiers in the first place — are exactly the environments where a malicious or compromised workflow editor could do the most damage.
## The Patch That Wasn't Enough
Patch bypasses have a particular kind of sting. The first vulnerability is a flaw. The bypass is an embarrassment — it says the original fix didn't understand the problem fully.
CVE-2026-27577 was patched in February. Security Joes was already looking at that fix when they found this one. The fact that they were specifically reviewing the previous patch suggests deliberate, methodical security research — not a chance discovery. They were asking a specific question: did the February fix actually close the attack surface, or did it just close one door while leaving a window cracked?
The answer was the window.
n8n uses an expression evaluation system that lets workflow authors embed dynamic logic — think template variables, conditionals, and computed values. Sandboxing this is genuinely hard. JavaScript-based sandboxes have a long and painful history of escapes, and n8n is not alone in struggling with the problem. But that context doesn't excuse shipping an incomplete fix.
The affected version ranges are <2.31.5 and >=2.32.0, <2.32.1. The fixes are in 2.31.5 and 2.32.1 respectively. If you're running n8n and you haven't checked your version today, stop reading and go check.
## The Broader Automation Platform Attack Surface
This vulnerability fits a pattern that doesn't get enough coverage: workflow automation platforms as lateral movement infrastructure.
The security conversation around tools like n8n, Zapier, Make, and Temporal tends to focus on credential management — don't store your API keys in plaintext, rotate your secrets, use environment variables. That's valid, but it misses the deeper issue. These platforms are, by design, credential aggregators that speak to everything. The workflow that sends Slack notifications when a Stripe payment arrives also has the Stripe API key, the Slack webhook, and probably a database connection string sitting in its configuration.
An attacker who can execute OS commands on an n8n host doesn't need to know which secrets the organization stored in the platform. They can just read the environment variables. Or dump the n8n database. Or pivot through any of the service integrations the automation team built.
This is what makes the "authenticated attacker" framing in vulnerability disclosures sometimes misleading. Yes, exploitation requires authentication. But the path to a valid n8n workflow editor account might be a phished credential, a compromised developer laptop, or — in a multi-tenant or SaaS-variant deployment — a legitimately provisioned account held by someone who turns out to be malicious. "Authenticated" is not the same as "not a real threat."
## What Defenders Should Do Right Now
The immediate action is straightforward: patch. If you're below 2.31.5 or running the 2.32.0 line below 2.32.1, you're exposed. The fixed versions are available now.
Beyond the patch, a few things worth reviewing:
Audit who has workflow-editor access. In organizations that have been using n8n for a while, this list tends to grow. People get provisioned for a project and never deprovisioned. Run the audit.
Review what credentials are stored in n8n. The platform often becomes the de-facto secrets manager for automation teams because it's convenient. Map what's in there — API keys, database connection strings, OAuth tokens — and evaluate whether any of them are over-privileged. Automation doesn't need admin-level database access to send a notification.
Look at how n8n is deployed. Is it running as root? Is it on a system with access to production infrastructure without network segmentation? The sandbox escape is serious, but the damage it can do is bounded by the OS-level permissions the n8n process holds and the network access it has. Defense in depth matters here.
Enable audit logging if you haven't. n8n supports workflow execution logs. If someone was poking at expression evaluation trying to find an escape, there may be traces. It's worth looking — especially if you were running a vulnerable version during the February-to-now window.
## HackWire Analysis
The real story here isn't the vulnerability itself — it's what this patch bypass says about the security maturity of the automation platform category as a whole.
n8n deserves credit for responding to Security Joes' research and shipping fixes across two version branches. That's the correct behavior. But the existence of a patch bypass reveals something important: the original CVE-2026-27577 fix was reactive rather than systematic. When you patch a sandbox escape by blocking a specific technique, you're playing whack-a-mole. The complete fix requires a structural understanding of why the sandbox boundary failed — and apparently that understanding wasn't fully in place in February.
This matters for the broader category because n8n is competing with, and increasingly being compared to, platforms that have invested heavily in sandboxing: Temporal, Pipedream, and others. The infrastructure automation space is growing fast, driven by AI-workflow integrations that are making these platforms more complex and more powerful simultaneously. More power means more attack surface.
There's also a supply-chain dimension worth flagging. n8n is increasingly used in enterprise AI pipelines — it's a common orchestration layer for LLM workflows, RAG systems, and agent tooling. An n8n instance with RCE exposure is, in some deployments, an AI pipeline with RCE exposure. The security posture of these automation layers is becoming a first-order concern for any organization building on top of them, and many have not treated it that way yet.
For security teams: this is a good moment to add automation platforms to your asset inventory and vulnerability management scope if they aren't there already. These tools aren't IT infrastructure in the traditional sense, but they're moving into a tier of criticality that demands the same rigor.
— HackWire Editorial
## Related Coverage