n8n schließt 18 Sicherheitslücken: Angreifer können Schadcode ausführen
Die Entwickler der Workflow-Automatisierungsplattform n8n haben in aktuellen Versionen insgesamt 18 Sicherheitslücken geschlossen. Mehrere davon erlauben es Angreifern im schlimmsten Fall, eigenen Code auf dem Server auszuführen und damit die betroffene Instanz vollständig zu übernehmen. Wer n8n selbst betreibt, sollte zeitnah aktualisieren.
n8n verbindet APIs, Datenbanken und interne Systeme und speichert dafür Zugangsdaten, API-Schlüssel und OAuth-Tokens. Eine kompromittierte Instanz ist deshalb kein Randproblem, sondern öffnet oft den Weg zu einem ganzen Netz angebundener Dienste. Genau das macht diese Lückenwelle relevant.
Die wichtigsten Schwachstellen
Über den Git-Node lassen sich bestimmte Konfigurationswerte so manipulieren, dass Angreifer eigene Befehle ausführen und Schadcode auf den n8n-Server bringen. Diese Werte lassen sich allerdings nicht ohne Weiteres verändern. Die Entwickler weisen darauf hin, dass ein Angreifer dafür zunächst eine separate Lücke ausnutzen muss, um überhaupt in diese Position zu gelangen.
Im JavaScript-Task-Runner sind Ausbrüche aus der Sandbox möglich. Die Sandbox soll dafür sorgen, dass in Workflows hinterlegter Code isoliert bleibt und nicht auf das darunterliegende System durchgreift. Gelingt der Ausbruch, kann im Anschluss Schadcode außerhalb dieser Isolierung laufen.
Auf der Abschlussseite von Formularen kann es zu einer gespeicherten Cross-Site-Scripting-Attacke kommen (Stored XSS). Dabei wird schädlicher Skriptcode dauerhaft abgelegt und später im Browser anderer Nutzer ausgeführt, was etwa zum Übernehmen von Sitzungen missbraucht werden kann.
Im MongoDB-Node können Angreifer Daten löschen. Zusätzlich lassen sich mit der Berechtigung role:manageProject Projekt-Rollen löschen und auf project:admin umbiegen, was einer Rechteausweitung innerhalb der Projektverwaltung gleichkommt.
Wer betroffen ist
Ein wiederkehrendes Muster zieht sich durch fast alle diese Lücken: Sie setzen einen bereits angemeldeten Nutzer voraus, der Workflows erstellen oder bearbeiten darf. Das relativiert die Gefahr nicht, sondern verschiebt den Fokus. In vielen n8n-Installationen sind Workflow-Rechte großzügiger vergeben, als es die tatsächliche Vertrauensstellung rechtfertigt. Wer solche Rechte an wenig vertrauenswürdige Konten vergibt oder eine kompromittierte Anmeldung erlebt, öffnet damit direkt den Weg zu Codeausführung.
Im Fokus stehen selbst gehostete Instanzen, weil deren Betreiber die Updates eigenständig einspielen müssen. n8n Cloud wird vom Anbieter selbst aktualisiert. Wie brisant das Thema ist, zeigt schon die Verbreitung: Scan-Dienste wie Censys zählten Anfang 2026 rund 26.500 offen erreichbare n8n-Hosts im Internet, ein erheblicher Teil davon in Deutschland.
Erneut n8n-Schwachstellen
Diese Meldung steht nicht für sich. n8n zieht seit Monaten eine ganze Serie von Advisory-Wellen hinter sich her. Erst vor rund drei Wochen, Mitte Juli, hatte das CERT-Bund des BSI eine Sammelmeldung zu 14 n8n-Schwachstellen unter der Kennung WID-SEC-2026-2267 veröffentlicht und die Gesamtlage mit einem CVSS-Wert von 9.9 als kritisch bewertet. Dass jetzt bereits die nächste Runde mit 18 weiteren Lücken folgt, unterstreicht einen Punkt, der bei n8n wichtiger ist als bei vielen anderen Werkzeugen: Wer die Plattform selbst betreibt, kommt um ein fortlaufendes Patch-Management nicht herum. Einmal aktualisieren und abhaken reicht hier nicht.
- n8n zeitnah auf die von den Entwicklern genannten gepatchten Versionen aktualisieren. Die genauen Versionsstände je nach Release-Zweig stehen in den Release-Ankündigungen und Advisories im n8n-GitHub-Repository.
- Falls ein sofortiges Update nicht möglich ist: die in den jeweiligen Warnmeldungen genannten temporären Absicherungsmaßnahmen umsetzen. Dazu gehört unter anderem, riskante Nodes gezielt zu deaktivieren.
- Nicht benötigte Nodes wie Git-Node oder Code-Node über die Umgebungsvariable NODES_EXCLUDE abschalten, solange sie nicht zwingend gebraucht werden.
- Falls ein sofortiges Update nicht möglich ist: die in den jeweiligen Warnmeldungen genannten temporären Absicherungsmaßnahmen umsetzen. Dazu gehört unter anderem, riskante Nodes gezielt zu deaktivieren.
- Nicht benötigte Nodes wie Git-Node oder Code-Node über die Umgebungsvariable NODES_EXCLUDE abschalten, solange sie nicht zwingend gebraucht werden.
- n8n nicht ungeschützt ins Internet stellen, sondern hinter Zugriffskontrollen betreiben und die Instanz wie kritische Infrastruktur behandeln.