Die eigentliche Gefahr von Workflow-Automatisierung ist nicht die Bequemlichkeit, sondern die Unsichtbarkeit: Ein n8n-Server, der irgendwo in einer Docker-Umgebung oder auf einem kleinen VPS läuft, wird schnell zum vergessenen Knotenpunkt, der Zugriff auf Datenbanken, Cloud-APIs, CRM-Systeme und interne APIs hat. Genau dort meldet das CERT-Bund des BSI aktuell 14 frisch geschlossene Schwachstellen – und ordnet das Gesamtrisiko mit CVSS 9.9 von 10.0 als kritisch ein. Wer n8n selbst hostet und glaubt, „nur ein internes Tool“ zu betreiben, unterschätzt damit die Angriffsfläche eines vollwertigen Automatisierungs-Backends.

Am 9. Juli 2026 veröffentlichte das CERT-Bund über seinen Warn- und Informationsdienst den Sicherheitshinweis WID-SEC-2026-2267 zu der quelloffenen Workflow-Plattform n8n. Der Hinweis verweist auf insgesamt 14 Advisories, die in den neuen Releases 2.29, 2.30.2 (Pre-Release) und 1.123.64 geschlossen wurden. Sieben der Lücken tragen die Einstufung „High“, die übrigen sieben „Moderate“. Obwohl einzelne GitHub-Advisories maximal mit 8.9 bewertet sind, sieht das BSI die kumulative Gefahr deutlich höher. Aktive Angriffe in freier Wildbahn werden bislang nicht berichtet – was jedoch kein Argument für Zögern ist, sondern ein Zeitfenster für das Update darstellt.

Was ist n8n – und warum ist es ein besonders attraktives Angriffsziel?

n8n ist eine quelloffene Plattform zur Workflow-Automatisierung, die es ermöglicht, verschiedene Online-Dienste, APIs, Datenbanken und interne Systeme über eine visuelle Node-basierte Oberfläche zu verknüpfen. Die Software wird häufig in Marketing-Stacks, DevOps-Pipelines, IT-Servicemanagement, E-Commerce-Integrationen und KI-Agenten-Workflows eingesetzt. Im Gegensatz zu reinen Cloud-Diensten wie Zapier oder Make lässt sich n8n selbst hosten – ein Modell, das bei datenschutzsensiblen Unternehmen, Behörden und IT-Dienstleistern besonders beliebt ist.

Self-Hosting versus Cloud: Freiheit mit Verantwortung

Beim Self-Hosting trägt der Betreiber die volle Verantwortung für Betriebssystem-Updates, Container-Härtung, Netzwerksegmentierung und das Einspielen von Sicherheitspatches. Die n8n Cloud wird vom Hersteller gepflegt; Kunden dort profitieren automatisch von Aktualisierungen. Self-Hosting-Betreiber hingegen müssen aktiv werden – und genau diese Gruppe adressiert die aktuelle CERT-Bund-Warnung. Die frei verfügbaren Releases auf GitHub sind zwar schnell verfügbar, aber sie müssen auch zeitnah eingespielt werden. Wer hier Wochen wartet, läuft Gefahr, dass öffentlich dokumentierte Schwachstellen für gezielte Angriffe ausgenutzt werden.

Ein weiterer Faktor ist die Verbreitung: n8n wird laut eigenen Angaben und Community-Schätzungen weltweit in mehreren zehntausend Installationen genutzt, davon ein erheblicher Anteil selbst gehostet. Viele dieser Instanzen laufen in internen Netzwerken, sind aber über das Internet erreichbar – sei es für Webhook-Trigger, API-Zugriffe oder das Management-Interface. Genau diese Erreichbarkeit macht sie zu einem lohnenswerten Ziel, wenn Anmeldedaten oder Schwachstellen ausgenutzt werden können.

Workflows als privilegierte Brücke zwischen Systemen

Ein Workflow in n8n ist mehr als eine Abfolge von Schritten: Er ist ein Programm mit Zugriff auf Passwörter, API-Keys, Datenbank-Credentials, OAuth-Tokens und oft auch auf interne Netzwerkressourcen. Typische Workflows lesen Kundendaten aus, schreiben in CRM-Systeme, versenden E-Mails, starten virtuelle Maschinen oder synchronisieren Datenbanken. Ein Angreifer, der eine Schwachstelle ausnutzt, um Code im Kontext der n8n-Anwendung auszuführen, erbt diese Rechte quasi automatisch.

Diese Architektur unterscheidet n8n fundamental von einer einfachen Webanwendung. Selbst eine Cross-Site-Scripting-Lücke kann in einem Tool mit Workflow-Ausführung und Credential-Speicher weitreichendere Folgen haben als in einem reinen Content-Management-System. Wer n8n betreibt, betreibt damit de facto eine Integrationsplattform mit administrativen Berechtigungen – und sollte sie auch so absichern. Die Warnung des CERT-Bund via heise online macht diesen Zusammenhang erneut deutlich.

Die CERT-Bund-Warnung WID-SEC-2026-2267 im Detail

Der deutsche Warn- und Informationsdienst des Bundesamtes für Sicherheit in der Informationstechnik (BSI) veröffentlicht regelmäßig Sicherheitshinweise zu kritischen Produkten. Die n8n-Meldung vom 9. Juli 2026 fällt auf, weil sie gleich 14 verschiedene Schwachstellen bündelt und das Gesamtrisiko mit dem höchstmöglichen Bereich „kritisch“ einstuft. Betroffen sind selbst gehostete n8n-Instanzen, die nicht auf die genannten aktuellen Releases aktualisiert wurden.

CVSS 9.9 – was die Einstufung bedeutet

Der Common Vulnerability Scoring System (CVSS)-Base-Score von 9.9 bedeutet, dass das BSI die Gesamtgefahr der 14 Lücken als kritisch einstuft. Zum Vergleich: Ein CVSS-Wert ab 9.0 gehört zur Kategorie „Critical“. Die Begründung liegt in der Kombination aus hoher Auswirkung und relativ niedriger Angriffskomplexität, wenn ein authentifizierter Benutzer die Lücken ausnutzt. Anders als bei einer einzelnen Remote-Code-Execution-Schwachstelle mit anonymem Zugriff ist hier die Authentifizierung eine wichtige Einschränkung – aber eben keine ausreichende, wenn ein normaler Workflow-Benutzer oder ein kompromittiertes Benutzerkonto zur Codeausführung führen kann.

Die Diskrepanz zwischen dem aggregierten CERT-Bund-Score von 9.9 und den einzelnen GitHub-Advisories, die maximal 8.9 („High“) erreichen, ist methodisch nachvollziehbar: GitHub bewertet jede Lücke isoliert, während das BSI die kumulative Auswirkung betrachtet. Werden mehrere Lücken kombiniert – beispielsweise eine Rechteausweitung mit einer anschließenden Codeausführung – ergibt sich ein höheres Gesamtrisiko. Zudem handelt es sich bei n8n um eine zentrale Integrationsplattform, sodass eine Kompromittierung weitreichende Folgen für das gesamte Unternehmensnetzwerk haben kann. Vergleichbare Einstufungen gab es zuletzt bei der Adobe ColdFusion-Warnung mit CVE-2026-48282 oder der Microsoft SharePoint-Lücke CVE-2026-45659.

Die betroffenen Versionen und die abgesicherten Releases

Laut Heise und dem n8n-Repository auf GitHub Security Advisories sollten Administratoren auf folgende Versionen umsteigen:

• n8n 2.29 – aktueller stabiler Release-Zweig
• n8n 2.30.2 – Pre-Release für Early-Adopter
• n8n 1.123.64 – Wartungsrelease für den älteren 1.x-Zweig

Welche der Versionen für eine konkrete Installation passt, hängt vom eingesetzten Branch, den Custom-Nodes und der Container-Infrastruktur ab. Unternehmen, die Docker Compose, Kubernetes oder ein Bare-Metal-Setup nutzen, sollten vor dem Update ein Backup der Datenbank und der Credentials anlegen, die Release-Notes prüfen und das Update in einer Staging-Umgebung testen. Ein blindes Update auf den neuesten Pre-Release ist dann ratsam, wenn keine Breaking Changes in den genutzten Nodes dokumentiert sind. Die offizielle Dokumentation zum Thema Hosting und Sicherheit findet sich unter docs.n8n.io/hosting/securing/.

Die sieben High-Risk-Lücken im Überblick

Von den 14 geschlossenen Schwachstellen sind sieben mit „High“ eingestuft. Drei davon erlauben unter bestimmten Voraussetzungen die Ausführung beliebigen Codes oder eine Rechteausweitung, zwei betreffen Cross-Site-Scripting, eine das AI-Agent-Feature und eine die Enterprise-SSO-Anbindung. Das breite Spektrum zeigt, dass die Lücken nicht nur an einer Stelle im Code liegen, sondern verschiedene Subsysteme betreffen.

Remote Code Execution via Git-Node und Legacy Expression Evaluator

Die höchstbewerteten Einzellücken mit GitHub-Scores von bis zu 8.9 betreffen die Git-Node und den sogenannten Legacy Expression Evaluator. Die Race-Condition in der Git-Node kann von authentifizierten Benutzern unter bestimmten Voraussetzungen zur Remote Code Execution missbraucht werden. Dabei ist die Angriffskomplexität laut Advisory als hoch eingestuft, was bedeutet, dass nicht jeder Angreifer sie sofort ausnutzen kann – aber dennoch ernst genommen werden muss, insbesondere in Multi-User-Umgebungen.

Der Bug im Legacy Expression Evaluator ermöglicht ebenfalls Codeausführung durch authentifizierte Nutzer. Expression Evaluator sind in n8n zentral, weil fast jeder Workflow mit JavaScript-Ausdrücken arbeitet, um Daten zu transformieren, Filter zu setzen oder dynamische Werte zu erzeugen. Wenn diese Auswertungsschicht nicht rigide sandboxiert ist, wird sie schnell zum Einfallstor. Administratoren sollten prüfen, ob Workflows mit benutzerdefinierten Ausdrücken von nicht vertrauenswürdigen Benutzern stammen und ob entsprechende Einschränkungen im User-Management aktiv sind.

JWT, XSS und Enterprise SSO – Angriffe über scheinbar harmlose Pfade

Eine dritte kritische Lücke ermöglicht eine Rechteausweitung und Codeausführung über JSON Web Tokens (JWT) durch Nutzer mit geringen Privilegien. JWTs werden in vielen modernen Anwendungen für die Authentifizierung und Autorisierung genutzt. Wenn die Validierung oder die Token-Verarbeitung fehlerhaft ist, kann ein Benutzer mit eingeschränkten Rechten Berechtigungen überschreiben, die eigentlich nur Administratoren vorbehalten sind.

Hinzu kommen zwei Cross-Site-Scripting-Schwachstellen (GHSA-p3rg-hrf9-w9gj und GHSA-9wcp-9r3j-383q). XSS mag auf den ersten Blick weniger dramatisch wirken als RCE, ist in einer Workflow-Plattform aber besonders gefährlich: Ein injizierter Script-Block kann Workflows manipulieren, Credentials auslesen oder Admin-Sessions übernehmen. Die sechste High-Lücke betrifft das AI-Agent-Feature, das in aktuellen n8n-Versionen zunehmend an Bedeutung gewinnt. Die siebte schließlich betrifft die Enterprise Single Sign-On (SSO)-Anbindung und erlaubt eine Rechteausweitung.

Was Unternehmen jetzt tun müssen: Update- und Härtungsplan

Die gute Nachricht: Es gibt keine bekannten aktiven Angriffe. Die schlechte Nachricht: Sobald die Details der Schwachstellen öffentlich sind, sinkt die Zeit bis zur ersten Ausnutzung drastisch. Administratoren sollten daher in den nächsten Tagen ein strukturiertes Vorgehen einleiten, das Update, Überwachung und Härtung kombiniert.

Sofortmaßnahmen: Inventur, Backup und Update

Der erste Schritt ist eine vollständige Inventur aller n8n-Instanzen im Unternehmen. Dazu gehören produktive Systeme, Staging-Umgebungen, Entwickler-Sandboxes und eventuell vergessene Testinstallationen. Häufig entstehen n8n-Instanzen durch einzelne Mitarbeiter oder Teams ohne zentrale Dokumentation. Ein Scan nach dem String „n8n“ in internen DNS-Einträgen, Container-Registries und Reverse-Proxy-Konfigurationen hilft, versteckte Instanzen aufzuspüren.

Anschließend sollte für jede Instanz ein Backup der Datenbank und der verschlüsselt gespeicherten Credentials angelegt werden. n8n speichert Credentials in verschlüsselter Form; ohne das korrekte N8N_ENCRYPTION_KEY-Wertepaar sind sie nach einem Restore nicht mehr nutzbar. Wer das Update auf 2.29, 2.30.2 oder 1.123.64 einspielt, sollte danach die Version im Admin-Interface oder per docker logs prüfen und alle Workflows in einem Testlauf validieren. Eine Staging-Umgebung ist hier unverzichtbar, um produktive Automationen nicht durch Breaking Changes zu unterbrechen.

Härtung, Netzwerksegmentierung und Monitoring

Ein Update allein reicht nicht aus, wenn die Instanz anschließend weiterhin unsicher erreichbar ist. n8n-Administratoren sollten das Management-Interface und die Webhook-Endpunkte über ein VPN oder interne Netzwerke abschotten, statt sie direkt aus dem Internet zugänglich zu machen. Wo ein öffentlicher Zugriff unvermeidlich ist, sollten mindestens ein Reverse-Proxy mit IP-Whitelisting, ein Web Application Firewall (WAF)-Layer und strikte Authentifizierung zum Einsatz kommen.

Zusätzlich empfiehlt sich eine Rollen- und Rechteüberprüfung. Nicht jeder Benutzer braucht Zugriff auf Credentials, Workflow-Execution oder AI-Agent-Konfigurationen. Die Enterprise-Edition bietet hier feinere Granularität als die Community-Version. Auch das Monitoring sollte erweitert werden: ungewöhnliche Workflow-Ausführungen, Login-Versuche von unbekannten IPs, geänderte Workflows und unerwartete Ausgänge sind Indikatoren, die zentral geloggt und alarmiert werden sollten. Ein Blick auf unseren Artikel zur Zero-Trust-Architektur zeigt, wie sich solche Integrationspunkte in ein ganzheitliches Sicherheitskonzept einbetten lassen.

Vergleich: n8n, Zapier und Make aus Sicherheitsperspektive

Die aktuelle Warnung wirft die Frage auf, ob Self-Hosting bei Workflow-Tools überhaupt noch sinnvoll ist. Die Antwort hängt vom Anwendungsfall ab. Die folgende Tabelle vergleicht n8n mit den bekannten Cloud-Alternativen Zapier und Make unter Sicherheitsaspekten.

Die Tabelle zeigt: Self-Hosting bietet maximale Kontrolle, verlangt aber auch maximale Sicherheitsdisziplin. Wer diese Disziplin nicht aufbringen kann, ist mit einem verwalteten Cloud-Dienst besser beraten – auch wenn das Compliance- und Kostenprofil anders aussieht. Die aktuelle n8n-Warnung ist daher weniger ein Plädoyer gegen Self-Hosting als ein Weckruf für bessere Patch-Hygiene.

Warum diese Warnung ein Symptom größerer Supply-Chain-Probleme ist

Die n8n-Lücken sind nicht isoliert. Sie passen in eine Entwicklung, in der Integrationsplattformen, Build-Pipelines und KI-Agenten-Frameworks zunehmend zur Schwachstelle in der Unternehmens-IT werden. Gleichzeitig mit der n8n-Warnung gab es in den letzten Wochen Meldungen zu kompromittierten npm-Paketen, gefälschten SDKs auf PyPI und manipulierten KI-Agenten-Skills. Die gemeinsame Ursache ist die wachsende Komplexität der Software-Supply-Chain.

Von n8n zur Supply-Chain: ein Kettenreaktions-Szenario

Stellen Sie sich folgendes Szenario vor: Ein Entwickler nutzt n8n, um bei jedem Git-Push automatisch Testläufe zu starten und Artefakte in ein internes Repository hochzuladen. Die Git-Node des Workflows ist durch die aktuelle Race-Condition angreifbar. Ein Angreifer, der ein kompromittiertes Entwicklerkonto nutzt, kann über den Workflow bösartigen Code in die Build-Pipeline einschleusen. Von dort aus verbreitet sich die Malware über interne Paketquellen, Docker-Images oder Deployment-Skripte. Was als „nur n8n“ begann, endet als Supply-Chain-Angriff.

Genau diese Kettenreaktionen beschreibt auch der aktuelle Verizon DBIR 2026, der KI-gestützte Angriffe und die Kompromittierung interner Systeme als einen der dominanten Trends der aktuellen Cybercrime-Landschaft nennt. Wer n8n als Self-Hosting-Plattform betreibt, muss deshalb nicht nur das n8n-Update einspielen, sondern auch die angeschlossenen Systeme im Blick behalten. Eine zentrale Workflow-Engine ist per Definition ein Supply-Chain-Element.

KI-Agenten-Features erweitern die Angriffsfläche

Eine der High-Lücken betrifft das AI-Agent-Feature von n8n. Damit reagiert n8n auf einen generellen Trend: Workflow-Plattformen integrieren immer stärker große Sprachmodelle, um Entscheidungen, Datenaufbereitung und Benutzerinteraktion zu automatisieren. KI-Agenten erhalten dabei Zugriff auf Tools, APIs und oft auch auf die gleichen Credentials wie klassische Workflows. Wenn diese Agenten-Schicht Schwachstellen enthält, kann ein Angreifer nicht nur Workflows manipulieren, sondern über gezielte Prompts oder Tool-Aufrufe Daten abfließen lassen oder Aktionen im Unternehmen auslösen.

Diese Gefahr ist nicht n8n-spezifisch. Auch andere KI-Agenten-Plattformen und Frameworks müssen ihre Tool-Integrationen rigide sandboxen und jede Aktion protokollieren. Für Unternehmen bedeutet das: Bevor man KI-Agenten in produktive Workflows einbaut, sollte man das Threat-Model aktualisieren. Die aktuelle n8n-Warnung ist ein frühes, aber deutliches Warnsignal, dass KI-Features in Integrationsplattformen zusätzliche Risiken mitbringen.

Im Fokus: Was Sie aus der CERT-Bund-n8n-Warnung mitnehmen sollten

Die Warnung WID-SEC-2026-2267 ist kein theoretisches Risiko, sondern ein konkreter Handlungsaufruf für alle, die n8n selbst hosten. Das BSI stuft die kumulative Gefahr der 14 geschlossenen Schwachstellen als kritisch ein, obwohl einzelne Lücken „nur“ mit High bewertet sind. Betroffen sind Self-Hosting-Installationen, die nicht auf die Releases 2.29, 2.30.2 oder 1.123.64 aktualisiert wurden.

• Update umgehend einspielen: Inventur aller n8n-Instanzen, Backup von Datenbank und Encryption-Key, Update auf 2.29, 2.30.2 oder 1.123.64, anschließend Tests in Staging.
• Netzwerk abschotten: Management-Interface nicht öffentlich erreichbar machen; VPN, IP-Whitelisting und WAF verwenden, wo direkter Zugriff nötig ist.
• Rechte minimieren: Rollenkonzept prüfen, keine unnötigen Admin-Rechte, Credentials nur für notwendige Workflows freigeben.
• Monitoring verstärken: Login-Versuche, Workflow-Änderungen, ungewöhnliche Ausführungen und externe API-Aufrufe zentral loggen und alarmieren.
• KI-Features bewusst einführen: AI-Agent-Workflows erst nach Härtung und mit isolierten Testdaten betreiben, da eine der High-Lücken direkt diese Komponente betrifft.

Wer diese Maßnahmen innerhalb der nächsten Tage umsetzt, nutzt das aktuelle Zeitfenster, bevor Angreifer die öffentlichen Advisories für gezielte Kampagnen verwenden. Die Quellen für diesen Artikel sind der CERT-Bund-Hinweis WID-SEC-2026-2267, die GitHub Security Advisories von n8n, die Release-Notes auf GitHub sowie die heise online-Meldung vom 9. Juli 2026. Zusätzliche Hintergründe zur generellen Sicherheitslage finden Sie in unseren Artikeln zu CISA-Warnungen und der Microsoft Patch Tuesday Auswertung.