A security research firm called Security Joes just broke through n8n's expression sandbox. Again.
This is the second time they've done it since February. Third bypass overall. And at some point the story stops being "update your n8n" and starts being: n8n's expression sandbox was not built to hold a hostile user — it was built to catch mistakes. Those are different problems.
If your team runs n8n for AI workflow automation — document processing pipelines, CRM integrations, internal chatbots, grant tracking — spend five minutes on this. Not because it's scary. Because the pattern it exposes is something most small orgs running self-hosted AI have never thought through.
What happened
In February 2026, Security Joes found CVE-2026-27577: an expression injection flaw that let authenticated users with workflow-editing permissions execute arbitrary system commands on the server running n8n. Not "do things in n8n" — run OS commands on the host machine, with n8n's process privileges.
n8n patched it. Security Joes went back, looked at the patch, and found a bypass. The result is GHSA-gv7g-jm28-cr3m, published July 27. n8n fixed this in versions 2.31.5 and 2.32.1.
The bypass worked because n8n's sandbox runs on two independent layers: a structural rewriter and a semantic denylist. The exploit hit a gap in both simultaneously — an arrow-function polyfill gap on the structural side and a Reflect.get string-argument gap on the semantic side. Neither gap alone was enough; together, they were. The advisory's pre-patch mitigation was to "restrict instance access and workflow editing to fully trusted users." Security Joes explicitly noted that's an incomplete short-term fix.
The architecture problem
n8n was designed for small teams where the people editing workflows are also the people running the instance. One admin. You trust everyone who has access. That's still most n8n deployments.
But n8n has become the default choice for building AI workflow backends — document pipelines, automated AI chatbots, data integration layers. In those setups, "people with workflow editing access" means something different. A team member who isn't a sysadmin. A contractor building an integration. A department lead who wants to tweak an automated report.
That's where architecture matters. n8n's sandbox is trying to make workflow expressions — the small JavaScript snippets inside nodes — safe to run on the host. But the repeated bypass pattern tells you something: this sandbox was designed to catch accidental bad inputs, not to hold someone specifically looking for a gap.
The distinction matters. Mistake-prevention sandboxes need to handle accidental bad inputs. Security sandboxes need to hold a sophisticated adversary. When Security Joes went back after the February patch specifically looking for a bypass, they found one in the same component.
This isn't unique to n8n. Flowise had a CVSS 10.0 RCE under active exploitation in April. Langflow had similar issues earlier this year. The pattern across self-hosted AI workflow tools is the same: expression evaluation and code execution are genuinely hard to sandbox securely, and these tools were built to ship workflows fast, not to hold hostile authenticated users.
What you should actually do
Update n8n now. If you're running anything before 2.31.5 (for pre-2.32 releases) or before 2.32.1 (for the 2.32 branch), patch it today. The exploit chain is documented. This isn't theoretical.
Audit who can create or modify workflows. This is the higher-leverage action. The vulnerability requires an authenticated account with workflow-editing permissions. If access is tightly scoped — only admins can create workflows — your exposure is much smaller. If "anyone with an n8n login" can create or edit workflows, you're relying on the sandbox as your only line of defense. After two bypasses in five months, that's not where you want to be.
Know what your n8n instance can reach. n8n workflows typically hold credentials for email, CRM, databases, cloud storage. OS command execution on the n8n host can touch all of that. Apply least-privilege to the n8n service account. If it only needs to read your database, don't give it write access. If it only needs one storage bucket, don't give it full storage admin. Blast radius matters when the sandbox fails.
Rethink whether multi-user n8n editing fits your setup. Single-admin deployments — one person builds the workflows, nobody else edits them — have a manageable risk profile with patching. Shared workspaces where multiple people create workflows are operating in territory where the sandbox has been bypassed twice by the same team, and the advisory itself calls access restriction "incomplete." That's worth a real conversation about your deployment model.
The bigger picture
This isn't really about n8n specifically. It's about a pattern in self-hosted AI tools that most orgs haven't thought through.
When you deploy self-hosted workflow automation, you get real benefits: data stays on your infrastructure, no API dependency, you control the stack. You also take on a new attack surface that the hosted SaaS version manages for you. The server is yours. The sandbox is yours to secure. The people editing workflows have a much more direct relationship with your infrastructure than a cloud API call does.
That tradeoff is often worth making — we help clients make it regularly. But it isn't free, and the security model is different from SaaS AI tools in ways that matter. The repeated n8n bypass pattern is a clean illustration of where that difference shows up.
What makes this specific pattern alarming isn't that there's a CVE. It's that the same researchers broke through the same mechanism twice. That's not a patching problem — that's an architecture audit.
Update. Scope workflow editing access down. Know what your instance can reach.
If you want help running through your self-hosted AI stack — n8n, Flowise, Langflow, or whatever else you're running — auditing access models and blast radius is a sprint we've done a few times. Happy to talk through what's worth looking at.