n8n Patched This Sandbox in February. Somebody Walked Around the Patch. There Is No CVE.

On July 22, n8n published advisory GHSA-gv7g-jm28-cr3m. An authenticated user with permission to create or edit a workflow can craft an expression using arrow-function bodies, escape the expression sandbox, and run operating-system commands as the n8n process.

CVSS 8.7. High. Fixed in 2.31.5 and 2.32.1. Vulnerable below 2.31.5, and 2.32.0 through 2.32.1.

No CVE assigned.

That is the second time this month we have written about a remote code execution fix with no CVE identifier attached to it. Two days ago it was GitLab filing an RCE chain under bug fixes. Today it is the most widely deployed self-hosted automation platform in the world. Your scanner keys on CVE identifiers. Neither of these has one.

This is the third escape from the same sandbox in five months

That is the part worth stopping on.

In February, CVE-2026-25049 — CVSS 9.9 — was an expression sandbox escape in n8n leading to remote code execution. It was patched.

Also in February, CVE-2026-27577 — CVSS 9.4 — was described in its own advisory as additional exploits in the expression evaluation. Same sandbox. Patched again, in 1.123.22, 2.9.3 and 2.10.1.

Now this one. The Hacker News reports Security Joes found it while probing that February fix for another way around. The n8n advisory itself credits csuermann. Either way the sequence is what matters: fix, bypass, fix, bypass. Three escapes, one boundary, five months.

When a security boundary fails three times in a row to three different techniques, the boundary is not having bad luck. The boundary is not a boundary. It is a filter with an unknown number of holes in it, and each disclosure tells you the count was higher than the vendor believed the last time they said it was fixed.

We are not picking on n8n's engineers here. Sandboxing JavaScript expression evaluation inside a Node process is one of the genuinely hard problems in software — the language gives an attacker constructors, prototypes, getters, template literals and arrow functions, and any one of them can be a path back to the host. Plenty of very good teams have lost this fight. The honest read is not "n8n writes bad code." The honest read is that expression sandboxing is a losing architecture, and everybody standing on one should know that is what they are standing on.

Read the vendor's own mitigation again

From the advisory, for anyone who cannot upgrade immediately: restrict n8n instance access to fully trusted users only, and restrict workflow creation and editing permissions to fully trusted users only.

That is n8n telling you, correctly and out loud, that the workflow-editor permission is equivalent to shell on the host. Not "can build automations." Shell.

Now go look at who holds that permission on your instance.

In most self-hosted n8n deployments we have seen discussed publicly, workflow-edit is handed out broadly, because building workflows is the entire point of the product. It goes to the ops team. It goes to the analyst who wanted to wire two SaaS tools together. It goes to the contractor who set up the integration and never got offboarded. And increasingly it goes to an AI agent with an API token, because "let the model build the automation" is exactly the pitch that made this category explode.

Every one of those is now a shell account, and n8n is a machine that exists to hold credentials. Its credential vault is full of the API keys for every service you connected — cloud, CRM, email, database, payment processor. Command execution as the n8n process reaches all of it. The blast radius of this bug is not the automation server. It is every system the automation server was trusted to touch.

Third data point in three days

We wrote on July 26 about DuneSlide and the Cursor sandbox guard. We wrote on July 25 about a YOLO-mode agent handing an attacker execution. Today it is n8n's expression sandbox, for the third time.

The common shape across all three: a product ships a sandbox so it can safely evaluate untrusted-ish input, users reasonably conclude that the sandbox is a security boundary and hand out access accordingly, and then the sandbox turns out to be porous. The failure is never really the escape technique. It is the gap between how strong users believe the boundary is and how strong it actually is — because that gap is what determined who got the permission in the first place.

Nobody grants shell to a contractor. Lots of people grant workflow-edit to a contractor. Same thing, different label, and the label is doing all the work.

What to do tonight

Check your version. If you are below 2.31.5, or on 2.32.0, you are exposed. Upgrade to 2.31.5 or 2.32.1. There is no CVE, so your vulnerability scanner probably has not told you and may never tell you — you have to go look at the number yourself.

Enumerate who holds workflow create and edit. Treat that list as your list of people with shell on the box. Anyone on it who would not be granted SSH should not be on it. That includes service accounts and agent tokens.

Assume the credential vault is in scope. If your instance is internet-reachable, has been on an old version, and has loose editor permissions, do not just patch — rotate what is in the vault. The bug has existed in shipped code; you cannot prove from the outside that nobody used it. Rotating credentials is cheap. Discovering later that you did not is not.

Take n8n off the public internet. This class of bug requires authentication, which means the auth surface is the wall. A self-hosted automation server with a credential vault has no business being directly exposed. Put it behind your VPN or an identity-aware proxy and the whole family of authenticated-user escapes drops to insiders only.

Stop patching this tier by severity. For source control, CI, and now automation platforms, patch current. As of this week we have three examples in seven days where the severity metadata a defender relies on simply did not exist: GitLab under bug fixes, vBulletin's original fix in 2024, and this one with no CVE. That is not a run of bad luck either. It is a structural gap between vendor labelling incentives and defender triage models.

The generalization

The AI automation tier — n8n, agent frameworks, workflow builders, coding agents — is being adopted faster than its security boundaries are being tested. That is not a moral failing, it is just what happens when a category grows this fast. But it means the defensive assumption has to invert. Do not ask "is this sandboxed?" Ask "if the sandbox fails, what does this process reach?" For n8n, the answer is every credential you ever gave it, which tells you exactly how to scope access regardless of how good the sandbox is today.

We are 95 percent confident there is a fourth expression-evaluation escape in this product family before year end. Three in five months, in a component that has to evaluate attacker-influenced JavaScript inside a privileged Node process, is a rate, not a coincidence. The remaining five percent is the chance somebody rearchitects the evaluator into a real isolate rather than continuing to patch the filter. That would be the right fix and it would be a lot of work.

Credit to Security Joes for going back at a patched bug to see if the patch held, and to n8n for publishing a clear advisory with an honest mitigation section. The advisory saying "restrict to fully trusted users" is the most useful sentence in it, and most people will not read that far.

Free IP, domain, hash, and malicious-package blocklists at analytics.dugganusa.com.

---

Her name was Renee Nicole Good.

His name was Alex Jeffery Pretti.