Leitfaden

n8n sicher betreiben: Risiken, bekannte Lücken und Härtung

Von Lucas Weber, CyberSec42 · Stand 28.10.2026

n8n ist ein lohnendes Angriffsziel, weil eine Instanz Zugangsdaten zu vielen anderen Systemen speichert, Code ausführen kann und über Webhooks aus dem Internet erreichbar ist. Wer n8n sicher betreiben will, hält die Instanz aktuell, stellt den Editor nicht offen ins Netz, schützt Konten mit Zwei-Faktor-Anmeldung, sichert jeden Webhook ab, sperrt nicht benötigte Code- und Befehls-Nodes und bewahrt den Verschlüsselungsschlüssel getrennt auf. Das BSI hat seit Januar 2026 mehrere Sicherheitshinweise zu n8n veröffentlicht, darunter einen mit der Einstufung „kritisch“.

Warum n8n ein lohnendes Ziel ist

n8n verbindet Anwendungen miteinander und automatisiert Abläufe zwischen ihnen. Damit das funktioniert, hinterlegen Sie in n8n Zugangsdaten: API-Schlüssel, OAuth-Tokens, Datenbankpasswörter, SMTP-Zugänge. Für einen Angreifer ist eine n8n-Instanz deshalb weniger ein einzelnes System als ein Sammelpunkt für Zugänge zu vielen Systemen. Drei Eigenschaften machen sie besonders attraktiv:

• Sie hält Zugangsdaten. n8n speichert Credentials verschlüsselt in der Datenbank. Wer die Instanz übernimmt, kann diese Zugänge in eigenen Workflows benutzen, ohne sie je im Klartext zu sehen.
• Sie führt Code aus. Code-Node, Ausdrücke in Feldern und, falls freigeschaltet, der Execute-Command-Node laufen auf dem Server. Eine Lücke in dieser Ausführung führt schnell zur Übernahme des ganzen Hosts.
• Sie ist von außen erreichbar. Webhooks, Formulare und Chat-Trigger sind absichtlich öffentlich ansprechbar, damit andere Dienste Workflows starten können. Jeder dieser Endpunkte ist ein Eingang.

Hinzu kommt der Inhalt der Ausführungen: n8n speichert je nach Einstellung die Daten jedes Durchlaufs, also Kundendaten, Bewerbungen, Rechnungen oder Gesprächsverläufe. Wer daran gelangt, hat oft personenbezogene Daten, deren Verlust eine Meldepflicht nach Art. 33 DSGVO auslösen kann. Ob das im Einzelfall zutrifft, ist eine Rechtsfrage. Dieser Artikel ist keine Rechtsberatung.

Welche Sicherheitslücken in n8n bekannt sind

n8n veröffentlicht Schwachstellen als Security Advisories im eigenen GitHub-Repository. Seit 2025 sind dort weit über hundert Hinweise erschienen, mehr als zwanzig davon als kritisch eingestuft (Stand 28.10.2026). Die hohe Zahl ist auch ein Zeichen dafür, dass der Hersteller Funde offenlegt und behebt. Für Betreiber heißt sie aber vor allem: Eine n8n-Instanz, die ein paar Monate nicht aktualisiert wurde, hat mit hoher Wahrscheinlichkeit bekannte Lücken offen.

Was das BSI zu n8n meldet

Ja, das BSI hat über den Warn- und Informationsdienst (WID) von CERT-Bund Sicherheitshinweise zu n8n veröffentlicht. Der erste davon, WID-SEC-W-2026-0040 vom Januar 2026, ist als „kritisch“ eingestuft. Er fasst drei Schwachstellen zusammen, darunter CVE-2026-21858 und CVE-2025-68613, und beschreibt, dass ein Angreifer beliebigen Programmcode ausführen, vertrauliche Informationen offenlegen und Sicherheitsmaßnahmen umgehen kann. Weitere Hinweise mit der Einstufung „hoch“ folgten unter anderem im Januar, Februar, März und Mai 2026 (WID-SEC-W-2026-0144, -0318, -0532, -0877 und -1519). Die Meldungen sind im Portal von CERT-Bund öffentlich einsehbar.

Ausgewählte Schwachstellen

Die folgende Auswahl zeigt die Bandbreite: von Lücken, die ohne Anmeldung ausnutzbar sind, bis zu solchen, die ein angemeldetes Konto voraussetzen. Die Versionsangaben stammen aus den Advisories des Herstellers und der NVD.

Zwei Lehren stecken in dieser Tabelle. Erstens reichen bei mehreren Lücken ein angemeldetes Konto oder ein erbeutetes Passwort, um den Server zu übernehmen. Wer allen Nutzern seiner Instanz nicht vollständig vertraut, muss Rechte und Nodes einschränken. Zweitens werden die Lücken auch in älteren Versionszweigen behoben. Stand 28.10.2026 ist 2.45.5 die stabile Version, der Zweig 1.123.x erhält weiter Sicherheitskorrekturen. Prüfen Sie für Ihre Instanz immer die aktuellen Advisories, statt sich auf eine Versionsnummer aus einem Artikel zu verlassen.

Typische Fehlkonfigurationen

Viele erfolgreiche Angriffe brauchen keine neue Lücke, sondern eine offene Tür im Betrieb. Die folgenden Punkte finden sich in selbst gehosteten Installationen besonders häufig. Die genannten Einstellungen stammen aus der offiziellen n8n-Dokumentation.

Der Editor ist offen im Internet

Die Weboberfläche von n8n ist ein Administrationswerkzeug. Sie muss nicht für die ganze Welt erreichbar sein, nur weil Webhooks es sein müssen. Legen Sie den Editor hinter ein VPN, einen Zugangsschutz am Reverse Proxy oder eine IP-Freigabeliste, und betreiben Sie ihn ausschließlich über HTTPS. Webhook-Pfade lassen sich am Proxy getrennt freigeben. Die Einstellung N8N_SECURE_COOKIE sorgt dafür, dass Sitzungs-Cookies nur über HTTPS übertragen werden. Sie steht in der Grundeinstellung auf true und sollte dort bleiben.

Schwache Anmeldung am Owner-Konto

Das Owner-Konto hat volle Kontrolle über die Instanz, alle Workflows und alle Zugangsdaten. Ein erratbares oder anderswo wiederverwendetes Passwort reicht, um die Lücken aus der Tabelle oben auszunutzen. Schalten Sie für alle Konten die Zwei-Faktor-Anmeldung ein. n8n unterstützt sie über eine Authenticator-App, und mit N8N_MFA_ENFORCED_ENABLED lässt sie sich für alle Nutzer erzwingen. Wo vorhanden, ist eine zentrale Anmeldung über SAML oder OIDC besser als lokale Passwörter. Geben Sie Rechte nach Bedarf: Wer nur Workflows ansieht, braucht keine Rechte zum Bearbeiten.

Webhooks ohne Authentifizierung

Ein Webhook ohne Schutz startet den Workflow für jeden, der die URL kennt oder errät. Der Webhook-Node von n8n bietet dafür mehrere Verfahren: Basic Auth, Header Auth, JWT Auth und die Anmeldung über n8n-Konten. Zusätzlich lässt sich eine IP-Freigabeliste hinterlegen, Anfragen von anderen Adressen erhalten dann eine 403-Antwort. Prüfen Sie außerdem, was der Workflow mit den eingehenden Daten tut. Wird ein Feld aus der Anfrage ungeprüft in eine Datenbankabfrage, einen Dateipfad oder einen Befehl eingesetzt, hilft die beste Authentifizierung nur gegen Fremde, nicht gegen manipulierte Daten.

Code-Node und Execute-Command-Node

Der Execute-Command-Node führt Befehle direkt auf dem Server aus. Seit n8n 2.0 sind er und der Local-File-Trigger in der Grundeinstellung gesperrt. Gesteuert wird das über NODES_EXCLUDE. Wer die Sperre aufgehoben hat, etwa mit NODES_EXCLUDE="[]", sollte prüfen, ob der Node wirklich gebraucht wird. Die Dokumentation nennt zusätzlich den Node „Read/Write Files from Disk“ als Kandidaten für die Sperrliste.

Für den Code-Node gilt: Seit Version 2.0 laufen Code-Ausführungen in sogenannten Task Runnern, also getrennt vom Hauptprozess. Die Dokumentation empfiehlt für zusätzliche Isolation den externen Modus. Setzen Sie außerdem N8N_BLOCK_ENV_ACCESS_IN_NODE=true, damit Code und Ausdrücke keine Umgebungsvariablen auslesen können, in denen oft Geheimnisse liegen. Mit N8N_RESTRICT_FILE_ACCESS_TO begrenzen Sie, auf welche Verzeichnisse Datei-Nodes zugreifen dürfen.

Community-Nodes als Lieferkettenrisiko

Community-Nodes sind Erweiterungen aus der npm-Registry. Die n8n-Dokumentation sagt dazu deutlich, dass sie vollen Zugriff auf den Rechner haben, auf dem n8n läuft, und auf alle Daten in den Workflows, die sie nutzen. Ein manipuliertes oder später übernommenes Paket ist damit ein direkter Weg in Ihre Instanz. Installieren Sie nur Pakete, die Sie wirklich brauchen, bevorzugen Sie von n8n geprüfte (verifizierte) Nodes und schalten Sie ungeprüfte Pakete mit N8N_UNVERIFIED_PACKAGES_ENABLED=false ab. Wer gar keine Community-Nodes nutzt, setzt N8N_COMMUNITY_PACKAGES_ENABLED=false.

Der Verschlüsselungsschlüssel

n8n verschlüsselt Zugangsdaten mit einem Schlüssel, den es beim ersten Start zufällig erzeugt und im Ordner ~/.n8n ablegt. Alternativ setzen Sie ihn selbst über N8N_ENCRYPTION_KEY, im Queue-Modus muss er auf allen Workern gleich gesetzt sein. Daraus folgen zwei Regeln. Erstens: Schlüssel und Datenbank gehören nicht gemeinsam in dasselbe Backup oder dasselbe Repository, denn wer beides hat, kann alle Zugangsdaten entschlüsseln. Zweitens: Ohne Schlüssel ist ein Datenbank-Backup für die Zugangsdaten wertlos. Bewahren Sie ihn deshalb getrennt und sicher auf, etwa in einem Passwort-Tresor. n8n bietet inzwischen eine Funktion zum Rotieren des Schlüssels, die Sie nach einem Verdachtsfall nutzen sollten.

Anfragen ins interne Netz

Der HTTP-Request-Node kann jede Adresse aufrufen, die der Server erreicht, auch interne Dienste und Metadaten-Endpunkte von Cloud-Anbietern. Ab Version 2.12.0 bietet n8n einen Schutz gegen solche Server-Side Request Forgery (SSRF), der über N8N_SSRF_PROTECTION_ENABLED=true eingeschaltet wird und dann unter anderem private Adressbereiche und Loopback blockiert. Die Dokumentation betont, dass dieser Schutz die Netzwerk-Firewall ergänzt, nicht ersetzt.

Updates ohne festen Rhythmus

Bei der Zahl der veröffentlichten Lücken ist ein fester Update-Rhythmus die wirksamste Einzelmaßnahme. Verfolgen Sie die Advisories im GitHub-Repository und die WID-Meldungen des BSI, spielen Sie Sicherheitsupdates zeitnah ein und prüfen Sie danach die wichtigsten Workflows. Wer auf einem alten Hauptversionszweig festsitzt, sollte den Umstieg planen, bevor dieser keine Korrekturen mehr erhält.

Selbst gehostet oder n8n Cloud

Bei n8n Cloud betreibt n8n den Server und spielt Plattform-Updates ein. Das nimmt Ihnen einen großen Teil der Server-Härtung ab. Es macht Ihre Instanz aber nicht automatisch sicher: Lücken wie CVE-2026-21877 betrafen laut Hersteller auch Cloud-Instanzen, und alles, was Sie selbst konfigurieren, bleibt Ihre Verantwortung.

KI-Agenten in n8n und Prompt-Injection

n8n bietet Nodes für KI-Agenten, die ein Sprachmodell mit Werkzeugen verbinden, sowie Nodes für das Model Context Protocol (MCP). Ein solcher Agent liest E-Mails, Tickets oder Webseiten und entscheidet dann, welches Werkzeug er aufruft. Genau das ist die Schwachstelle: Text in den gelesenen Daten kann Anweisungen enthalten, denen das Modell folgt. Diese Prompt-Injection lässt sich nicht vollständig wegfiltern. Wirksam ist, die Werkzeuge des Agenten so zu begrenzen, dass eine untergeschobene Anweisung keinen großen Schaden anrichten kann, und Aktionen mit Folgen, etwa Zahlungen, Löschungen oder Mails nach außen, von einer menschlichen Freigabe abhängig zu machen.

Wie Prompt-Injection und Tool-Poisoning im Detail ablaufen, beschreiben wir in Prompt-Injection und Tool-Poisoning in MCP-Servern. Die Vertrauensgrenzen eines Agenten und wie man sie absichert, erklärt KI-Agenten absichern: der praktische Überblick.

Härtungs-Checkliste für n8n

Was der eingebaute Security-Audit leistet und was nicht

n8n bringt einen eigenen Security-Audit mit, aufrufbar über die Kommandozeile mit n8n audit, über die API oder über den n8n-Node. Er listet unter anderem ungenutzte Zugangsdaten, Ausdrücke in SQL-Abfragen, Nodes mit Dateizugriff, riskante eingebaute Nodes, installierte Community-Nodes, ungeschützte Webhooks und eine veraltete n8n-Version. Das ist ein guter regelmäßiger Startpunkt.

Der Audit bewertet aber die Konfiguration, nicht die Logik Ihrer Workflows. Ob ein Webhook-Feld ungeprüft in einer Datenbankabfrage landet, ob ein KI-Agent sich über eine präparierte E-Mail zu einer Aktion bewegen lässt oder ob ein angebundenes Konto viel mehr Rechte hat als nötig, zeigt erst eine Prüfung, die die Workflows so angreift, wie es ein Angreifer tun würde.

Häufige Fragen

Weiterlesen

• KI-Agenten absichern: der praktische Überblick
• Prompt-Injection und Tool-Poisoning in MCP-Servern
• Die OWASP Top 10 für Agentic AI, praktisch erklärt
• Leistung: KI- und MCP-Sicherheitsprüfung

Quellen

• n8n auf GitHub: Security Advisories
• GHSA-v4pr-fm98-w9pg (CVE-2026-21858)
• GHSA-v98v-ff95-f3cp (CVE-2025-68613)
• GHSA-v364-rw7m-3263 (CVE-2026-21877)
• GHSA-62r4-hw23-cc8v (CVE-2025-68668)
• GHSA-365g-vjw2-grx8 (Execute-Command-Node)
• NVD: CVE-2025-68613
• CISA: Known Exploited Vulnerabilities Catalog
• BSI CERT-Bund: WID-SEC-W-2026-0040
• n8n Docs: Security environment variables
• n8n Docs: v2.0 Breaking changes
• n8n Docs: Block specific nodes
• n8n Docs: Community nodes risks
• n8n Docs: Set a custom encryption key
• n8n Docs: Enable SSRF protection
• n8n Docs: Run security audits
• EUR-Lex: Datenschutz-Grundverordnung (EU) 2016/679