n8n Patches Sandbox Escape That Let Editors Run Commands on the Server
A flaw in the popular automation platform let anyone with workflow-editing access break out of the safe zone and run system commands. n8n has issued a fix.
Key points
- n8n has patched a high-severity flaw in its automation platform that let authenticated workflow editors run operating-system commands on the server.
- The bug was found by researchers at Security Joes while checking whether an earlier February fix for CVE-2026-27577 could be bypassed.
- Affected versions are anything before 2.31.5, and the 2.32.0 release.
- Fixed builds are 2.31.5 and 2.32.1; users should update straight away.
- Exploitation requires an account that can edit workflows, so the risk is highest for teams with many internal editors or loose access controls.
n8n, an open-source tool that lets companies stitch together apps and automate tasks without writing much code, has fixed a serious security flaw. The bug let someone who could already log in and edit workflows escape the platform's safety cage and run commands directly on the machine hosting it.
In plain terms: the app runs user-written snippets inside a sandbox, a walled-off area meant to stop those snippets touching the wider system. Researchers found a way through the wall.
The finding comes from Security Joes, an incident response firm that went digging after n8n shipped a February patch for a similar issue. They wanted to know if the earlier fix could be worked around. It could.
How serious is this?
Serious, but not a drive-by. An attacker needs an account on the n8n instance with permission to edit workflows. That rules out random internet strangers, but it does not rule out a rogue insider, a contractor whose access was never revoked, or an outsider who phished a valid login.
Once inside, the attacker can run commands as the n8n process itself. That means reading files the server can see, pulling secrets and API keys stored for automations, and pivoting to whatever systems n8n connects to. For many companies, that connection list is long: CRMs, databases, cloud accounts, internal tools.
Which versions are affected?
The flaw sits in a broad slice of recent releases. n8n has published the specifics, first reported by The Hacker News.
| Status | Version range |
|---|---|
| Vulnerable | Before 2.31.5 |
| Vulnerable | 2.32.0 |
| Patched | 2.31.5 |
| Patched | 2.32.1 |
If you self-host n8n, check your version now. Cloud-hosted customers are updated by n8n directly.
How did the researchers find it?
By assuming the first fix was not the last word. Security Joes treated the February patch, tracked as CVE-2026-27577, as a starting point rather than a finish line. They probed the same sandbox from a fresh angle and found another way to break out.
That is a common pattern with sandbox escapes. The underlying design, running untrusted code inside a language runtime and hoping it stays put, is hard to get right. One patch often closes a door while leaving a window ajar.
What should n8n users do now?
Update. Move self-hosted instances to 2.31.5 or 2.32.1 as soon as your change process allows. If you cannot patch immediately, tighten who can edit workflows: audit the user list, remove dormant accounts, and require strong authentication on every editor login.
After patching, treat the incident as a prompt to review what your automations can actually reach. If a single workflow can touch production databases, cloud billing and customer email, ask whether it should. Least privilege applies to bots as much as to people.
There is no public report of the flaw being exploited in the wild. That can change quickly once patch details circulate, so speed matters.
