On July 22, 2026, n8n shipped fixes for GHSA-gv7g-jm28-cr3m , a sandbox escape vulnerability rated 8.7 on CVSS 4.0. Any authenticated user with permission to create or edit a workflow could craft a JavaScript expression that broke out of n8n's expression sandbox and ran operating system commands as the n8n process. If you run self-hosted n8n, this is worth 15 minutes of your afternoon: check your version, and if you are not on 2.31.5 or 2.32.1, patch today.
This post walks through what the advisory actually says, why the sandbox failed again five months after n8n's last public fix, how to tell if you are exposed, and what a hardened n8n setup looks like once you are patched.
GHSA-gv7g-jm28-cr3m is a GitHub Security Advisory published by n8n on July 22, 2026, describing an expression sandbox escape via arrow-function bodies that enables command execution . n8n lets workflow authors write JavaScript expressions inline (to transform data between nodes), and those expressions run inside a restricted sandbox so a workflow editor cannot reach the underlying server. The advisory documents a way around that restriction.
No CVE has been assigned to this advisory as of this writing. n8n tracks and discloses it directly through GitHub's security advisory system, which is why the GHSA ID, not a CVE number, is the reference to use when you check your dependency scanners or vulnerability trackers.
Security researchers at Security Joes found the bug while probing whether n8n's earlier fix for a separate flaw, CVE-2026-27577, had fully closed the sandbox. It had not. According to the technical writeups, the bypass needs two narrow gaps working together:
Chained together, those two blind spots let a crafted expression call out to the operating system from inside what was supposed to be a sandboxed data transform. That is a textbook sandbox escape : the vulnerable code path was not a missing permission check, it was a rewriter that stopped one syntax pattern short of covering all of them.
Steal our production automations
This is a self-hosted n8n issue. If you run n8n Cloud, the vendor's own infrastructure is patched on your behalf. If you self-host n8n (Docker, a VM, Kubernetes, or on your own cloud account), you are exposed until you upgrade.
Exploitation requires an authenticated account with permission to create or modify a workflow. That is a lower bar than it sounds in most real deployments: shared n8n instances often hand editor access to marketing ops, RevOps, support, and contractors, not just the security-conscious engineering team that set it up. Any one of those accounts, or any credential that leaks from one of them, is enough.
This is not n8n's first expression sandbox bypass in 2026. CVE-2026-27577, an earlier expression-escape issue with a near-maximum CVSS score, was patched in February. Security Joes found GHSA-gv7g-jm28-cr3m by specifically testing whether that fix held up under a second, different bypass technique, and it did not, at least not completely.
That pattern is not unique to n8n. Any product that lets end users write arbitrary expressions and then tries to sandbox those expressions inside the same language runtime is fighting a genuinely hard problem: a JavaScript sandbox implemented as a rewriter or an interceptor has to anticipate every syntax variant an attacker might use to reach the same underlying object. Miss one, and the sandbox is not a sandbox. It is worth treating "we patched the expression sandbox" as an ongoing commitment, not a one-time fix, for any workflow platform your team relies on.
Patching closes this specific hole. A hardened n8n deployment goes further:
That last point is the practical reason many teams stop trying to own n8n security themselves. Watching GitHub advisories, testing patches against a production workflow library, and reviewing editor permissions is a recurring job, not a one-time setup task. Our n8n development and support agency does exactly that: we build, harden, and maintain n8n instances for teams that would rather have a partner own the patch cycle than track it themselves. If you need a broader automation build, not just an n8n instance kept current, our custom workflow automation service covers the same ground for the rest of your stack.
A sandbox escape rated 8.7 on CVSS 4.0 is now patched in n8n 2.31.5 and 2.32.1. If you self-host, check your version today. If you cannot patch immediately, cut workflow-editor access down to a trusted few and watch for unfamiliar arrow-function expressions until you can.
GHSA-gv7g-jm28-cr3m is n8n's GitHub Security Advisory for an expression sandbox escape, disclosed July 22, 2026, that let an authenticated workflow editor run operating system commands on the host running n8n. It is rated 8.7 on CVSS 4.0 and carries no CVE assignment as of this writing.
No. This issue affects self-hosted n8n deployments running an unpatched version. n8n Cloud runs on infrastructure the vendor patches directly, so cloud customers are not exposed to this specific advisory.
Versions below 2.31.5, and the 2.32.0.x line up to but not including 2.32.1, are affected. n8n 2.31.5 and 2.32.1 both contain the fix, so upgrading to either resolves the issue.
Review recent workflow expressions for arrow-function syntax you did not write, unexplained use of Reflect.get , or references to Node's process object inside data-transform nodes. Also check for unexpected shell processes (bash, PowerShell, curl, wget) spawned as children of the n8n process, since a successful exploit runs commands that way.
No. n8n's own advisory describes permission restrictions as a short-term mitigation, not a fix, because the underlying sandbox bypass is still present until you upgrade. Patching to 2.31.5 or 2.32.1 is the only complete remediation.
The February fix addressed CVE-2026-27577, a different expression-escape technique. Security Joes found GHSA-gv7g-jm28-cr3m by testing that same patch for a second, unrelated bypass path (arrow-function bodies combined with a Reflect.get denylist gap), and found one. It shows how hard it is to fully close an expression sandbox built as a syntax rewriter rather than a true isolated runtime.
If your team is not actively watching n8n's security advisories, testing patches, and auditing workflow-editor permissions on a schedule, a managed setup removes that gap. Our n8n development and support agency handles patch monitoring, hardening, and ongoing maintenance for teams running n8n in production.
Sources: n8n GitHub Security Advisory GHSA-gv7g-jm28-cr3m , The Hacker News: n8n Sandbox Escape Lets Workflow Editors Run OS Commands as the n8n Process , Security Joes: Breaking the Sandbox Again
n8n has the deepest native AI agent-building capability and is open source; Make gives non-developers more visual logic control; Zapier has the widest app coverage. Here is the honest feature, pricing, and fit comparison for 2026.
An OpenAI eval agent broke its sandbox and breached Hugging Face. The practical playbook for scoped permissions, egress control, and approval gates so your agents cannot do the same.
OpenAI's agent breached Hugging Face and a state-linked-suspected actor ran an unattended agent against Thailand's finance ministry. What both incidents mean for teams building AI agents.
Book a Free Strategy Call
Walid runs a 30-min call to map your AI engineering team. Free, no slides.
Steal our production automations
Walid founded AY Automate to help businesses ship AI workflows that actually move revenue. He leads strategy and oversees every client engagement end-to-end.
The full story
This article is one source in a clustered incident — the cluster page carries the summary, timeline and every other outlet covering it.
