CVE-2026-27577 in n8n: When the Patch Itself Is Bypassed

Anyone running n8n self-hosted knows the routine: read security notices, upgrade the version, check it off. With CVE-2026-27577, this routine wasn't enough. The vulnerability was patched on February 25, 2026, and in July 2026, security researchers bypassed that very patch again.

This is no slip-up, but the fourth documented attack on the same component in eight months. For self-hosted instances, that changes the question: not whether you've deployed a specific update, but whether you have a process that catches follow-up findings on the same component. We've described the general situation in n8n Security Vulnerabilities 2026. This post focuses on the bypass itself.

What is CVE-2026-27577 exactly?

CVE-2026-27577 is a critical vulnerability in n8n's expression evaluation that allows an authenticated user with permission to create or modify workflows to execute system commands on the host via crafted expressions in workflow parameters.

The NVD lists the vulnerability with CVSS 3.1 of 9.9 (critical) and weakness class CWE-94, Code Injection. GitHub Security Advisory GHSA-vpcf-gvg4-6qwr additionally rates it CVSS 4.0 of 9.4. Affected are all versions before 1.123.22, the 2.x series from 2.0.0 before 2.9.3, and 2.10.0. It is patched in 1.123.22, 2.9.3, and 2.10.1, all three published on npm on February 25, 2026.

Important for context: n8n explicitly describes CVE-2026-27577 in its own advisory as a follow-up to CVE-2025-68613, the original expression evaluation vulnerability from December 2025. Between them was already CVE-2026-25049 from February 4, 2026, also CVSS 3.1 of 9.9, also another way around the same protection mechanism.

Why was the patch for CVE-2026-27577 bypassed in July 2026?

The fix for CVE-2026-27577 closed the specifically reported attack path, but not the underlying vulnerability in the expression rewriter. Security firm Security Joes demonstrated in July 2026 that the same access to the Node.js runtime can be achieved via a different language construct.

Technisch beschreibt Security Joes zwei Blindstellen, die einzeln harmlos sind und erst zusammen greifen: Die Umschreibung freier Bezeichner überspringt Pfeilfunktionen, sodass ein Ausdruck der Form „Pfeilfunktion, die das Prozess-Objekt zurückgibt“ am Schutz vorbeiläuft, und die Sperrliste für gefährliche Eigenschaften prüft nur statisch notierte Namen, greift also nicht, wenn derselbe Name als Zeichenkette übergeben wird. Verifiziert wurde das laut Veröffentlichung auf n8n 2.30.4, also auf einem Stand nach der Patch-Linie zu CVE-2026-27577 (Quelle: Security Joes, „Breaking the Sandbox Again“, 27. Juli 2026).

Der Ablauf spricht für den Hersteller: Security Joes meldete den Fund am 15. Juli 2026 über das Vulnerability-Disclosure-Programm von n8n, am 22. Juli 2026 war der Fix ausgerollt und das Advisory GHSA-gv7g-jm28-cr3m veröffentlicht, bewertet mit CVSS 4.0 von 8,7. Gepatcht ist dieser Weg in 2.31.5 und 2.32.1. Am selben Tag veröffentlichte n8n mit CVE-2026-65591 (CVSS 4.0 von 8,9) noch eine zweite Umgehung derselben Art im älteren Ausdrucks-Auswerter, gepatcht in 1.123.64, 2.29.8 und 2.30.1.

Which n8n version is now secure?

Safe against all bypasses mentioned here are only versions 1.123.67 or later, 2.31.5, or 2.32.1, as the July patches are beyond the patch line for CVE-2026-27577. Anyone who updated to 1.123.22 or 2.10.1 in February 2026 and has done nothing since is vulnerable.

• Expression vulnerability CVE-2025-68613 (December 2025): fixed in 1.120.4, 1.121.1, and 1.122.0.
• Bypass CVE-2026-25049 (February 4, 2026): fixed in 1.123.17 and 2.5.2.
• Bypass CVE-2026-27577 (February 25, 2026): fixed in 1.123.22, 2.9.3, and 2.10.1.
• Bypass CVE-2026-65591 (July 22, 2026): fixed in 1.123.64, 2.29.8, and 2.30.1.
• Bypass via arrow functions, GHSA-gv7g-jm28-cr3m (July 22, 2026): fixed in 2.31.5 and 2.32.1.

At the time of writing, 2.32.7 from July 31, 2026 is the current stable version on npm. You can find your instance's version number in the interface settings.

Who is allowed to edit workflows at your place?

All vulnerabilities in this series require an authenticated account with permission to create or modify workflows. This makes permission management in n8n not a comfort setting, but a security boundary: whoever is allowed to edit workflows stands, with an open bypass, on the same level as a user with shell access to the server.

In many installations that we take over, simply everyone has edit permissions because that was fastest during setup and nobody has rolled it back since. For managed instances, we therefore always check not only the version but also who holds edit permissions and whether the interface needs to be accessible from the open internet at all. Both of these belong in our ongoing management of an n8n instance, not in ad-hoc actions following the next headline. ongoing management of an n8n instance

What should self-hosters do now?

The only complete protection is an update, as the n8n advisories themselves state. The interim measures mentioned there mitigate the situation but expressly do not resolve it.

• Check and update version: to at least 1.123.67, 2.31.5, or 2.32.1, or better yet to the current stable release.
• Limit editing permissions: only those who actually need it for their work should be allowed to create and modify workflows. This is n8n's own recommended interim measure.
• Rotate credentials if you ran on a vulnerable version for an extended time: Security Joes recommends rotating the instance's encryption key and stored access credentials in this case, as a successful attack would have access to them.
• Do not expose the interface directly to the internet: access via VPN or a secured reverse proxy, see hardening guidance in n8n documentation.
• Monitor advisories continuously: subscribe to n8n's GitHub Security Advisories and schedule regular update windows instead of reacting on-demand.

This CVE series shows why the mundane advice is the critical one: between the patch of February 25 and that of July 22, nearly five months passed during which a correctly updated instance was still vulnerable as soon as someone found the next bypass. n8n provides detailed hardening guidance at docs.n8n.io.

Frequently Asked Questions

Is n8n Cloud affected by CVE-2026-27577?

n8n updates its own cloud environment internally; patch management is the vendor's responsibility there. The practical risk from this CVE series primarily affects self-hosted instances that are not updated promptly. The permissions problem persists in both operational models, as an account with workflow-editing rights is a prerequisite for the attack.

Is it enough to update to 1.123.22 or 2.10.1?

No, that only addresses CVE-2026-27577 itself. The bypasses of the same protection mechanism published in July 2026 are only fixed from 1.123.67, 2.31.5, and 2.32.1 respectively, and the bypass in the older evaluator from 1.123.64, 2.29.8, and 2.30.1.

How can I tell if my instance was exploited?

There is no reliable remote detection indicator. It makes sense to check the execution history for workflows with unusual expressions in node parameters and to check outbound connections from the server. If exploitation is suspected, follow the principle from Security Joes' publication: treat and rotate credentials as compromised.

Why does the same component get hit four times?

Because n8n's expression evaluator must allow users to run JavaScript while simultaneously shielding it from the server's runtime. Each patch initially closes the reported path. Security Joes formulates this very pattern: the fix for CVE-2026-27577 was correct for the reported case but did not ask the more general question about other bypassed language constructs.

Does NordFlux help secure existing n8n instances?

Yes. We check version status, permission settings, and access protection of existing installations and can take over ongoing update management if desired. An overview of our work with n8n can be found on our n8n service page.