SURIQ
An automation server is a credential vault wearing a workflow editor's clothes. Self-hosted n8n holds the API keys, database passwords, and cloud tokens for every service its workflows touch, so the question that matters is not whether the box is valuable. It is who can reach the vault. A patch released on July 22 answers that badly: anyone allowed to create or edit a workflow could break out of n8n's expression sandbox and run commands as the process on the host. The advisory is GHSA-gv7g-jm28-cr3m, and it carries a CVSS 4.0 score of 8.7.
No CVE has been assigned yet, and neither the vendor nor reporting from The Hacker News notes any exploitation in the wild. That is the good news and the whole window. A fix exists, the bug class is well understood, and the details are now public, so the gap between patched and unpatched instances is the only thing standing between an ordinary internal user and code on your automation host.
The bug: an expression field that reaches the shell
n8n lets you drop small JavaScript expressions into workflow fields, and a sandbox is supposed to keep that code from touching the underlying system. Security Joes, the firm credited with reporting the issue, found two weak points that together break out of it. One is that the sandbox left arrow-function bodies unguarded, so an expression written as an arrow could reach the genuine Node.js runtime object the sandbox was meant to hide behind a guarded copy. The other is that the sandbox screened property access by name, a check that fell over once the same property was fetched indirectly. Put together, those two gaps give an expression a path from the workflow editor down to child_process and a real shell.
The affected and fixed builds split across two release lines, so check which one you run:
-
Vulnerable: every n8n release below
2.31.5, plus2.32.0. -
Fixed:
2.31.5on the older line,2.32.1on the current line. -
No 1.x fix: there is no patched build on the legacy 1.x series, so anything still on 1.x has to move up a line to get out of range.
The severity math records the one precondition that matters: a low-privilege account and no user interaction. The attacker needs to be able to edit a workflow. It does not need an admin login, and it does not need to trick anyone into clicking.
Why "workflow editor" is now the role to worry about
In most n8n deployments, the permission to build and edit workflows is not a high-trust grant. It goes to the automation team, to analysts wiring up integrations, sometimes to contractors, sometimes to a broad internal group because the whole point of the tool is to let people automate their own tasks. The mental model is that these users move data between systems inside guardrails. This flaw erases the guardrail. On a vulnerable build, "can edit a workflow" reads as "can run commands as the n8n service account," and those are not remotely the same trust level.
That is why the blast radius is wrong if you measure it at the host. Command execution as the n8n process reaches N8N_ENCRYPTION_KEY, the secret n8n uses to encrypt stored credentials at rest. The Hacker News reporting notes that recovering it lets an attacker decrypt every credential the instance holds. So the real exposure is the set of systems n8n was built to reach: the production databases, the cloud accounts, the SaaS APIs, the internal webhooks. An automation hub concentrates access by design, which makes it a high-value pivot the moment the sandbox stops holding. We have written before about self-hosted builder tools that quietly grant far more than their role implies, from a single Budibase app reading server secrets to a dev-tool config that ran with a user's AWS keys. Same shape here.
The second escape of the same sandbox in five months
This is not the first time n8n's expression sandbox has been shown to be porous. The Hacker News reports that Security Joes found this bypass while going back over the patch n8n shipped in February for CVE-2026-27577, an earlier escape of the same feature. Two breaks of one sandbox in roughly five months is the pattern worth sitting with, and it is not unique to n8n. An expression sandbox built on top of a shared JavaScript runtime is a filter, not a boundary. It tries to enumerate the dangerous ways out and block each one, which means every new language trick or reflection path is a fresh candidate for a bypass. We have watched the same story play out with an AI coding agent that trusted the content it read and with Langflow, another self-hosted automation platform. The lesson for architects is to treat the sandbox as defense in depth, never as the thing that lets you widen who can edit workflows.
How to know if it was already used
Patching closes the hole. It does not tell you whether someone walked through it first, and with no published indicators of compromise, detection here is behavioral rather than signature-based. The tell is the automation engine doing something it should almost never do: spawning a shell. On a healthy host, the n8n process runs Node and talks to the network. It does not fork /bin/sh or bash. So the hunt is process lineage: alert when the n8n service account is the parent of a shell or of any non-Node child process, and pair that with unexpected outbound connections from the automation host to destinations its workflows do not normally reach. If you keep workflow definitions under review, arrow-function expressions inside expression fields are worth a second look, since that is the mechanism the public write-up describes. This is the runtime-behavior signal a managed detection layer is meant to surface: the process that suddenly acts out of character, not a known-bad file.
Update to 2.32.1 or 2.31.5, then rotate what n8n could reach
Two actions, in order. First, upgrade: move to 2.32.1 if you are on the current line or 2.31.5 on the older one, and off 1.x entirely. The advisory's interim advice, restricting workflow editing to trusted users, is a stopgap the vendor itself calls incomplete, so treat it as a bridge to the patch, not a substitute. Second, assume the encryption key was reachable on any instance that ran a vulnerable build with editors you do not fully trust, and rotate the credentials n8n stores for downstream systems. Reset the API keys, database passwords, and cloud tokens that a decrypted credential store would have exposed. Upgrading stops the next attempt. Rotation is what closes the door on anyone who was already inside the window.