n8n Sandbox Escape (CVSS 8.7): Patch and Harden Now

n8n Sandbox Escape (CVSS 8.7): Patch and Harden Now

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.

What is GHSA-gv7g-jm28-cr3m?

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.

How the escape actually works

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:

• n8n's expression rewriter did not correctly rewrite arrow functions with concise bodies (the shorthand (x) => x.value form, without curly braces), which let an attacker reach Node.js globals such as process directly.
• A separate denylist check built around Reflect.get() did not account for how that method can be used to reach process.getBuiltinModule, which can then load the child_process module.

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.

Who is affected

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.

Is your instance vulnerable? Check this first

1. Check your n8n version. In the UI, it is in Settings, or check the n8n --version output on the host, or the image tag if you run it in Docker.
2. Compare against the affected ranges. You are exposed if you are running anything below 2.31.5, or anything in the 2.32.0.x line before 2.32.1.
3. Review recent workflow edits for anything unusual. Look for expressions containing arrow functions you did not write, unfamiliar use of Reflect.get, or references to process inside a data-transform node. Security Joes' writeup also recommends checking for unexpected child processes (shells, PowerShell, curl, wget) spawned by the n8n process itself.
4. Audit who has workflow-editor access. If the answer is "more people than we can name from memory," that alone is a finding worth acting on regardless of this specific CVSS score.

How to patch and mitigate today

• Upgrade to 2.31.5 or 2.32.1 (or later). This is the only complete fix. n8n's own guidance is explicit that workarounds below are short-term only.
• If you cannot upgrade immediately, restrict who can create or edit workflows to a small, trusted group, and restrict who can access the n8n instance at all. This narrows the blast radius but does not close the hole.
• Rotate credentials stored in n8n if you find any sign of the mitigations above having already been bypassed, since a successful escape runs as the n8n process and can reach whatever that process can reach: environment variables, connected credentials, and the host filesystem.
• Run n8n with the least host privilege it needs. A sandbox escape that lands on a process with broad filesystem and network access is a much worse day than one that lands on a locked-down container with scoped secrets and no outbound access it does not need.

Why this keeps happening

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.

Hardening n8n beyond the patch

Patching closes this specific hole. A hardened n8n deployment goes further:

• Workflow-editor access limited to the people who actually need to build or change automations, reviewed on a schedule, not left to grow by default.
• Credentials scoped per-workflow where the platform supports it, instead of one shared service account with broad reach.
• Outbound network access from the n8n host restricted to what its integrations actually need.
• A patch cadence that treats n8n security advisories as a standing input, not something you find out about from a headline.

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.

Key takeaway

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.

FAQ

What is GHSA-gv7g-jm28-cr3m?

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.

Is n8n Cloud affected by this vulnerability?

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.

Which n8n versions are vulnerable?

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.

How do I check if my n8n instance was exploited?

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.

Does restricting workflow-editor permissions fully fix this?

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.

Why did n8n's sandbox get bypassed again after the February patch?

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.

Should I have someone else manage my n8n security?

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