n8n-Sicherheitslücken August 2026: Was Self-Hosting-Teams jetzt prüfen müssen

Wer n8n selbst hostet, bekommt es normalerweise nicht mit, wenn der Anbieter eine Lücke schließt — Updates laufen im eigenen Tempo, oft erst beim nächsten geplanten Wartungsfenster. Am 20. August 2026 hat n8n neun Sicherheitslücken gleichzeitig veröffentlicht, sechs davon mit dem Schweregrad „hoch". Für Teams, die n8n produktiv auf eigener Infrastruktur betreiben, ist das kein Update, das man auf später schieben sollte.

TL;DR

• Laut der Sicherheitsmitteilung von n8n (öffnet in neuem Tab) vom 20. August 2026 wurden neun Schwachstellen bekannt: sechs mit hohem, drei mit mittlerem Schweregrad.
• Betroffen sind alle Versionen unterhalb von 1.123.73 (v1-Linie), 2.35.4 (stabile 2.x-Linie) und 2.36.2 (Beta-Linie) — n8n Cloud ist laut derselben Mitteilung automatisch gepatcht, nur Self-Hosting-Instanzen müssen selbst aktualisieren.
• Die schwerste Lücke, GHSA-9x83-43r8-5hwc (öffnet in neuem Tab), erlaubt mit CVSS-Wert 8,7 aus der Workflow-Erstellung heraus Codeausführung auf dem n8n-Host — ganz ohne Administratorrechte.
• Zwei weitere Lücken (GHSA-vrv8-j27g-g7cr (öffnet in neuem Tab), GHSA-4r56-g65c-fm83 (öffnet in neuem Tab)) betreffen nicht die Codeausführung, sondern das Auslesen fremder Zugangsdaten über normale Nutzerrechte.
• Keine der sechs kritischen Lücken hat bislang eine eigene CVE-Nummer — das erschwert automatisierte Schwachstellen-Scans, die nur nach CVE-IDs suchen.

Was genau gemeldet wurde

n8n veröffentlicht solche Sammelmeldungen nach eigener Aussage im Zwei-Wochen-Rhythmus: „This is your bi-weekly security update from n8n", schreibt das n8n-Security-Team in der Mitteilung vom 20. August (öffnet in neuem Tab). Diesmal waren neun Advisories dabei, sechs davon mit hohem Schweregrad. Alle sechs betreffen Versionen unterhalb von 1.123.73 in der v1-Linie, unterhalb von 2.35.4 in der stabilen 2.x-Linie und unterhalb von 2.36.2 in der Beta-Linie.

Wichtig für die Einordnung: Laut den GitHub-Advisories (öffnet in neuem Tab) tragen alle sechs High-Severity-Lücken den Vermerk „No known CVE" — es gibt also (noch) keine offizielle CVE-Nummer. Wer Schwachstellen-Scanner betreibt, die ausschließlich nach CVE-IDs suchen, wird diese Lücken möglicherweise nicht automatisch finden. Die GHSA-Kennungen (GitHub Security Advisory) sind hier die verlässlichere Referenz.

Die kritischste Lücke: Codeausführung ohne Sonderrechte

GHSA-9x83-43r8-5hwc (öffnet in neuem Tab) trägt mit einem CVSS-4.0-Wert von 8,7 den höchsten Schweregrad der Sammelmeldung. Der technische Kern laut Advisory: Die $fromAI-Funktion löste einen vom Aufrufer übergebenen Platzhalternamen auf, ohne zu prüfen, ob es sich um eine eigene Eigenschaft handelt, und akzeptierte dabei auch reservierte Schlüsselnamen. Gegen einen primitiven Eingabewert lieferte das eine lebende Referenz auf den Host-Prototyp zurück — ein Ausdruck konnte diese Referenz bis zum Function-Konstruktor durchlaufen und dort Code kompilieren, der direkt im n8n-Hauptprozess läuft. Die Angriffsvoraussetzung ist laut Advisory allein die Berechtigung, Workflows zu bauen — keine Administratorrolle nötig.

Der zweite Fund mit hohem Schweregrad betrifft den Git-Node: Laut GHSA-mwp5-2m32-r54h (öffnet in neuem Tab) (CVSS 7,7) setzte n8n vor jeder Git-Operation nur eine feste Liste bekannter, befehlstragender Konfigurationsschlüssel zurück — Content-Filter- und Merge-Driver-Schlüssel waren davon nicht erfasst. Ein Repository mit entsprechend präparierter lokaler Konfiguration konnte dadurch bei einem gewöhnlichen Add, Commit, Checkout oder Pull einen hinterlegten Befehl ausführen lassen, mit den Rechten des n8n-Prozesses.

Beide Lücken sind in den bereits genannten Versionen (1.123.73, 2.35.4, 2.36.2) behoben.

Die stillere Gefahr: Zugangsdaten im Klartext

Zwei weitere High-Severity-Meldungen führen zu keiner Codeausführung, sondern zum Auslesen fremder Zugangsdaten — und sind deshalb leicht zu unterschätzen.

Laut GHSA-vrv8-j27g-g7cr (öffnet in neuem Tab) (CVSS 7,1) sendeten die Nodes für Strapi, SeaTable und Mailcheck ihre entschlüsselten Zugangsdaten über einen veralteten HTTP-Hilfsmechanismus an den Authentifizierungs-Endpunkt — außerhalb jeder Fehlerbehandlung. Jeder authentifizierte Nutzer konnte das Klartext-Geheimnis anschließend aus der eigenen Ausführung über die REST-API zurücklesen, obwohl die Zugangsdaten-API solche Werte eigentlich als Leerwert maskiert. Das Advisory empfiehlt ausdrücklich, bestehende Ausführungsprotokolle auf unerwartete Zugangsdaten in Strapi-, SeaTable- und Mailcheck-Fehlern zu prüfen und betroffene Zugangsdaten zu rotieren — ein einfaches Update allein reicht hier nicht, weil bereits gespeicherte Protokolle die Geheimnisse enthalten können.

Die zweite Lücke, GHSA-4r56-g65c-fm83 (öffnet in neuem Tab) (CVSS 7,2), betrifft geteilte Workflows: Ein Editor mit Zugriff auf einen geteilten Workflow — oder jeder Nutzer, der über REST-API, Public API oder MCP einen Workflow anlegt — konnte laut Advisory einen Workflow-Tool-Node mit eingebettetem Unter-Workflow platzieren, der auf eine Zugangsdaten-Referenz verweist, die der Bearbeiter selbst gar nicht besitzt. Führte später jemand mit den passenden Rechten den Workflow aus, löste der eingebettete Unter-Workflow das Geheimnis auf und konnte es an einen von Angreifern kontrollierten Endpunkt senden — ohne dass die Zugangsdaten je regulär geteilt worden wären. Diese Lücke betrifft laut Advisory ausschließlich die 2.x-Linie (behoben ab 2.35.4 beziehungsweise 2.36.2), nicht die v1-Linie.

Wer betroffen ist

Nach der n8n-Mitteilung (öffnet in neuem Tab) gilt: Wer n8n Cloud nutzt, ist automatisch gepatcht und muss nichts tun. Betroffen sind ausschließlich selbst gehostete Instanzen unterhalb der genannten Versionsgrenzen — also genau die Betriebsform, für die sich Unternehmen aus Kostengründen oder wegen Datenkontrolle typischerweise entscheiden.

Sofortmaßnahmen für Self-Hosting-Teams

1. Version prüfen. In der n8n-Oberfläche unten links oder per n8n --version auf der Konsole nachsehen. Liegt die Version unter 1.123.73 (v1) beziehungsweise unter 2.35.4 (stabile 2.x-Linie), besteht Handlungsbedarf.
2. Aktualisieren. Der Upgrade-Leitfaden von n8n (öffnet in neuem Tab) beschreibt das Vorgehen für die eigene Installationsart. Bei Docker Compose genügt in der Regel, das Image-Tag auf eine der gepatchten Versionen zu setzen und den Container neu zu starten.
3. Falls ein sofortiges Update nicht möglich ist, nennen die Advisories konkrete Zwischenmaßnahmen: den Zugriff auf die n8n-Instanz auf vertrauenswürdige Nutzer beschränken, KI-bezogene Nodes deaktivieren, wenn sie nicht gebraucht werden, betroffene Nodes wie den Git-Node über die Umgebungsvariable NODES_EXCLUDE sperren, und den n8n-Prozess unter einem eigenen, gering privilegierten Betriebssystem-Nutzer laufen lassen. Alle Advisories betonen ausdrücklich, dass diese Maßnahmen das Risiko nur mindern, nicht beseitigen.
4. Ausführungsprotokolle auf betroffene Nodes prüfen. Wer Strapi-, SeaTable- oder Mailcheck-Nodes im Einsatz hat, sollte bestehende Ausführungsdaten auf unerwartet sichtbare Zugangsdaten durchsehen und betroffene Zugangsdaten vorsorglich rotieren.
5. Geteilte Workflows durchsehen. Bei Workflow-Tool-Nodes mit eingebetteten Unter-Workflows prüfen, ob referenzierte Zugangsdaten tatsächlich dem Ersteller gehören — besonders bei Workflows, die mehrere Personen bearbeiten.

Warum das kein Einzelfall bleiben wird

Der zweiwöchige Rhythmus der Sicherheitsmitteilungen ist bei n8n mittlerweile Routine, nicht die Ausnahme. Gleichzeitig wächst die Angriffsfläche mit jeder neuen Version: Laut den offiziellen Release Notes (öffnet in neuem Tab) veröffentlicht n8n „a new minor version most weeks" — allein im August 2026 erschienen die Versionen 2.35 (11. August) und 2.36 (18. August), jeweils mit neuen Nodes und KI-Funktionen. Mehr Funktionsumfang bedeutet mehr Code, der geprüft werden muss, und die aktuelle Sammelmeldung zeigt, dass gerade die neueren KI-Funktionen wie $fromAI nicht von Schwachstellen ausgenommen sind.

Für Teams, die n8n selbst betreiben, folgt daraus eine simple Konsequenz: Ein Update-Prozess, der Sicherheitsmitteilungen tatsächlich verfolgt statt sie bei Gelegenheit einzuspielen, gehört zum Betrieb dazu — nicht als einmalige Maßnahme, sondern als wiederkehrende Aufgabe, ähnlich wie bei jeder anderen selbst gehosteten Infrastruktur. Wer diesen Prozess nicht selbst aufbauen will oder kann, sollte das bei der Entscheidung zwischen Self-Hosting und einer verwalteten Cloud-Instanz mit einpreisen.