n8n: Zwölf Lücken geschlossen. Was Betreiber eigener Instanzen jetzt tun

Kurz gesagt

Der Hersteller der Automatisierungsplattform n8n hat am 28. Oktober zwölf Sicherheitslücken geschlossen, drei davon mit hoher Stufe; das CERT-Bund des BSI stuft die Lage als „hoch“ ein. Wer n8n selbst betreibt, sollte auf eine aktuelle Version wechseln, mindestens 2.45.5 oder 2.46.1. Und prüfen, wer in der Instanz Workflows anlegen darf.

Was ist passiert?

n8n verbindet Programme miteinander: Ein Formular landet im CRM, eine Rechnung in der Buchhaltung, eine Anfrage beim KI-Modell. Wer n8n selbst betreibt, behält die Daten im eigenen Haus, ist aber auch selbst für Updates zuständig.

Am 28. Oktober hat n8n zwölf Sicherheitshinweise veröffentlicht, am selben Tag kam die Meldung des CERT-Bund (die Warnstelle des BSI für IT-Sicherheitslücken). Die drei schwersten Lücken erlauben es, Programmcode auf dem Server auszuführen, auf dem n8n läuft. Zwei davon setzen ein Konto voraus, das Workflows anlegen oder bearbeiten darf. Die dritte steckt im Baustein zur Bildbearbeitung und greift, wenn dieser Bilder von außen verarbeitet. Die übrigen neun betreffen einzelne Bausteine, etwa Chat-Fenster, OAuth-Anmeldungen und Datenbankanbindungen.

Hinweise auf aktive Ausnutzung gibt es bisher nicht: Keine der Lücken steht im Katalog der US-Behörde CISA.

Was bedeutet das?

In n8n liegen die Zugangsdaten zu allem, was es verbindet: CRM, E-Mail, Buchhaltung, KI-Anbieter. Wer Code auf dem n8n-Server ausführen kann, kommt im schlimmsten Fall an all diese Schlüssel.

Zwei der drei schweren Lücken brauchen ein Konto mit Bearbeitungsrecht. Das klingt beruhigend, ist es aber nur, wenn klar ist, wer solche Konten hat. In vielen Instanzen sind es mehr Personen als nötig: ehemalige Praktikanten, die Agentur, ein Testkonto. Das Update ist der erste Schritt, die Rechteprüfung der zweite.

Eine Besonderheit: Nach dem Update lassen sich die alten Bausteine „Function“ und „Function Item“ nicht mehr neu einsetzen. Bestehende Workflows laufen weiter, sollten aber auf den Baustein „Code“ umgestellt werden.

Was Sie jetzt tun können

1. Version feststellen. Beim Dienstleister oder Administrator erfragen. Maßgeblich ist die Version der laufenden Instanz, nicht die, die irgendwo in einer Konfigurationsdatei notiert ist.
2. Aktualisieren. Auf 2.45.5 oder neuer (stabile Reihe, aktuell 2.45.7) bzw. 2.46.1 oder neuer. Bei Docker: Image mit fester Versionsnummer neu ziehen und Container neu starten. Vorher Datenbank sichern.
3. Alte 1.x-Instanzen: 1.123.89 schließt mehrere der Lücken. Für die Lücke in den alten Code-Bausteinen (CVE-2026-119408) nennt der CVE-Eintrag keine Korrektur in 1.x. Den Umstieg auf 2.x mit dem Dienstleister planen.
4. Konten durchsehen. In der Benutzerverwaltung von n8n: Wer darf Workflows anlegen oder bearbeiten? Nicht mehr benötigte Konten löschen, Rechte auf das Nötige kürzen.
5. Alte Bausteine ersetzen. Workflows mit „Function“, „Function Item“ oder „LangChain Code“ auf den Baustein „Code“ umstellen lassen. Die Einstellung N8N_DEPRECATED_NODES_BLOCK=false nicht setzen, sie öffnet die Lücke wieder.
6. Wenn das Update warten muss: Bausteine über die Umgebungsvariable NODES_EXCLUDE sperren und den Zugang auf vertrauenswürdige Personen beschränken. Der Hersteller sagt selbst: Das ist nur eine Überbrückung.
7. Für den Dienstleister als Vorlage: „Bitte bestätigen Sie, dass unsere n8n-Instanz auf Version 2.45.5, 2.46.1 oder neuer läuft, nennen Sie die genaue Version und das Datum des Updates, und schicken Sie uns die Liste der Konten mit Bearbeitungsrecht.“

Häufige Fragen

Wir nutzen n8n nur für ein paar einfache Abläufe. Ist das wichtig? Ja. Entscheidend ist nicht die Zahl der Workflows, sondern welche Zugangsdaten darin gespeichert sind. Ist n8n jetzt unsicher? Nein. Zwölf geschlossene Lücken zeigen, dass gesucht und behoben wird. Unsicher wird es, wenn niemand aktualisiert. Werden die Lücken schon ausgenutzt? Bisher gibt es dafür keinen öffentlichen Beleg. Das kann sich ändern, sobald Einzelheiten bekannt sind.

Quellen

• CERT-Bund: WID-SEC-2026-4192, n8n: Mehrere Schwachstellen (28. Oktober 2026, Update 30. Oktober 2026)
• n8n: Security Advisories auf GitHub (28. Oktober 2026)
• n8n: Deprecated Code Nodes Allow Code Execution in the n8n Main Process (GHSA-9p7v-45m2-wxgj) (28. Oktober 2026)
• n8n: Insufficient Isolation in Workflow Expression Evaluation (GHSA-gx3v-3x3v-f8r5) (28. Oktober 2026)

Stand: 31. Oktober 2026. Ersetzt keine Prüfung im Einzelfall. Transparenz: Diese Einordnung ist KI-generiert mit menschlicher Prüfung, gekennzeichnet nach Art. 50 der europäischen KI-Verordnung. Auswahl, Quellenprüfung und Freigabe: Schoonnect.