CVE-2026-27577 in n8n: Wenn der Patch selbst umgangen wird

Wer n8n selbst betreibt, kennt die Routine: Sicherheitsmeldung lesen, Version hochziehen, Haken dran. Bei CVE-2026-27577 hat diese Routine nicht gereicht. Die Lücke wurde am 25. Februar 2026 gepatcht, und im Juli 2026 haben Sicherheitsforscher genau diesen Patch erneut umgangen.

Das ist kein Ausrutscher, sondern der vierte dokumentierte Anlauf auf dieselbe Komponente innerhalb von acht Monaten. Für selbst gehostete Instanzen ändert das die Frage: Nicht ob Sie ein bestimmtes Update eingespielt haben, sondern ob Sie einen Prozess haben, der Nachschläge auf dieselbe Stelle mitbekommt. Die allgemeine Lage haben wir in n8n-Sicherheitslücken 2026 beschrieben. Dieser Beitrag geht auf den Bypass selbst.

Was ist CVE-2026-27577 genau?

CVE-2026-27577 ist eine kritische Schwachstelle in der Ausdrucks-Auswertung von n8n, über die ein angemeldeter Nutzer mit dem Recht, Workflows anzulegen oder zu ändern, über präparierte Ausdrücke in Workflow-Parametern Systembefehle auf dem Host ausführen kann.

Das NVD führt die Lücke mit CVSS 3.1 von 9,9 (kritisch) und der Schwachstellenklasse CWE-94, Code Injection. Das GitHub Security Advisory GHSA-vpcf-gvg4-6qwr bewertet sie zusätzlich nach CVSS 4.0 mit 9,4. Betroffen sind alle Stände vor 1.123.22, die 2.x-Reihe ab 2.0.0 vor 2.9.3 sowie 2.10.0. Gepatcht ist sie in 1.123.22, 2.9.3 und 2.10.1, alle drei am 25. Februar 2026 auf npm veröffentlicht.

Wichtig für die Einordnung: n8n beschreibt CVE-2026-27577 im eigenen Advisory ausdrücklich als Nachtrag zu CVE-2025-68613, der ursprünglichen Lücke in der Ausdrucks-Auswertung aus dem Dezember 2025. Dazwischen lag bereits CVE-2026-25049 vom 4. Februar 2026, ebenfalls CVSS 3.1 von 9,9, ebenfalls ein Weg um denselben Schutzmechanismus herum.

Warum wurde der Patch zu CVE-2026-27577 im Juli 2026 umgangen?

Der Fix zu CVE-2026-27577 hat den konkret gemeldeten Angriffsweg geschlossen, aber nicht die dahinterliegende Lücke im Umschreiber der Ausdrücke. Das Sicherheitsunternehmen Security Joes hat im Juli 2026 gezeigt, dass sich derselbe Zugriff auf die Node.js-Laufzeit über einen anderen Sprachbaustein erreichen lässt.

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.

Welcher n8n-Stand ist jetzt sicher?

Sicher gegenüber allen hier genannten Umgehungen ist erst ein Stand ab 1.123.67, 2.31.5 oder 2.32.1, denn die Juli-Patches liegen hinter der Patch-Linie zu CVE-2026-27577. Wer im Februar 2026 auf 1.123.22 oder 2.10.1 aktualisiert hat und seitdem nichts getan hat, ist angreifbar.

• Ausdrucks-Lücke CVE-2025-68613 (Dezember 2025): behoben in 1.120.4, 1.121.1 und 1.122.0.
• Umgehung CVE-2026-25049 (4. Februar 2026): behoben in 1.123.17 und 2.5.2.
• Umgehung CVE-2026-27577 (25. Februar 2026): behoben in 1.123.22, 2.9.3 und 2.10.1.
• Umgehung CVE-2026-65591 (22. Juli 2026): behoben in 1.123.64, 2.29.8 und 2.30.1.
• Umgehung über Pfeilfunktionen, GHSA-gv7g-jm28-cr3m (22. Juli 2026): behoben in 2.31.5 und 2.32.1.

Zum Redaktionsschluss dieses Beitrags ist 2.32.7 vom 31. Juli 2026 der aktuelle stabile Stand auf npm. Die Versionsnummer Ihrer Instanz finden Sie in den Einstellungen der Oberfläche.

Wer darf bei Ihnen eigentlich Workflows bearbeiten?

Alle Lücken dieser Reihe setzen ein angemeldetes Konto mit dem Recht voraus, Workflows anzulegen oder zu ändern. Damit ist die Rechtevergabe in n8n keine Komforteinstellung, sondern eine Sicherheitsgrenze: Wer Workflows bearbeiten darf, steht bei einer offenen Umgehung faktisch auf derselben Stufe wie ein Nutzer mit Shell-Zugang zum Server.

In vielen Installationen, die wir übernehmen, haben schlicht alle Beteiligten Bearbeitungsrechte, weil das beim Aufbau am schnellsten ging und danach niemand zurückgedreht hat. Bei betreuten Instanzen prüfen wir deshalb neben dem Versionsstand immer, wer Bearbeitungsrechte hält und ob die Oberfläche überhaupt aus dem offenen Internet erreichbar sein muss. Beides gehört bei uns in den laufenden Betrieb einer n8n-Instanz und nicht in eine Sonderaktion nach der nächsten Schlagzeile.

Was sollten Selbst-Hoster jetzt tun?

Der einzige vollständige Schutz ist das Update, das sagen die n8n-Advisories selbst. Die dort genannten Übergangsmaßnahmen entschärfen die Lage, beheben sie aber ausdrücklich nicht.

• Version prüfen und aktualisieren: mindestens auf 1.123.67, 2.31.5 oder 2.32.1, besser auf den aktuellen stabilen Stand.
• Bearbeitungsrechte zusammenstreichen: Workflows anlegen und ändern darf nur, wer das für seine Arbeit wirklich braucht. Das ist die von n8n selbst empfohlene Übergangsmaßnahme.
• Zugänge nachziehen, wenn Sie längere Zeit auf einem verwundbaren Stand liefen: Security Joes empfiehlt, in diesem Fall den Verschlüsselungsschlüssel der Instanz und die hinterlegten Zugangsdaten zu tauschen, weil ein erfolgreicher Angriff genau daran kommt.
• Oberfläche nicht offen ins Internet hängen: Zugriff über VPN oder einen abgesicherten Reverse-Proxy, siehe die Härtungshinweise in der n8n-Dokumentation.
• Meldungen dauerhaft verfolgen: die GitHub-Security-Advisories von n8n abonnieren und ein festes Update-Fenster einplanen, statt auf Zuruf zu reagieren.

Diese CVE-Reihe zeigt, warum der banale Ratschlag der entscheidende ist: Zwischen dem Patch vom 25. Februar und dem vom 22. Juli lagen knapp fünf Monate, in denen eine korrekt aktualisierte Instanz trotzdem angreifbar war, sobald jemand den nächsten Weg fand. Ausführliche Härtungshinweise stellt n8n unter docs.n8n.io bereit.

Häufige Fragen

Ist n8n Cloud von CVE-2026-27577 betroffen?

n8n aktualisiert die eigene Cloud-Umgebung selbst, das Patch-Management liegt dort beim Anbieter. Die praktische Gefahr aus dieser CVE-Reihe trifft vor allem selbst gehostete Instanzen, die nicht zeitnah nachgezogen werden. Das Rechteproblem bleibt in beiden Betriebsmodellen bestehen, denn ein Konto mit Workflow-Bearbeitungsrechten ist die Voraussetzung für den Angriff.

Reicht es, auf 1.123.22 oder 2.10.1 zu aktualisieren?

Nein, das schließt nur CVE-2026-27577 selbst. Die im Juli 2026 veröffentlichten Umgehungen desselben Schutzmechanismus sind erst ab 1.123.67, 2.31.5 beziehungsweise 2.32.1 behoben, die Umgehung im älteren Auswerter ab 1.123.64, 2.29.8 und 2.30.1.

Woran erkenne ich, ob meine Instanz ausgenutzt wurde?

Ein sicheres Erkennungsmerkmal aus der Ferne gibt es nicht. Sinnvoll sind ein Blick in die Ausführungshistorie auf Workflows mit ungewöhnlichen Ausdrücken in Node-Parametern und die Prüfung ausgehender Verbindungen des Servers. Bei Verdacht gilt der Grundsatz aus der Veröffentlichung von Security Joes: Zugangsdaten als kompromittiert behandeln und tauschen.

Warum trifft dieselbe Komponente viermal?

Weil die Ausdrucks-Auswertung von n8n JavaScript von Nutzern ausführbar machen muss und es gleichzeitig von der Laufzeit des Servers abschirmen soll. Jeder Patch schließt zunächst den gemeldeten Weg. Security Joes formuliert genau das als Muster: Der Fix zu CVE-2026-27577 war für den gemeldeten Fall korrekt, hat aber die allgemeinere Frage nach weiteren übersprungenen Sprachbausteinen nicht gestellt.

Hilft NordFlux beim Absichern bestehender n8n-Instanzen?

Ja. Wir prüfen Versionsstand, Rechtevergabe und Zugriffsschutz bestehender Installationen und übernehmen auf Wunsch das laufende Update-Management. Einen Überblick über unsere Arbeit mit n8n finden Sie auf der Leistungsseite zu n8n.