Wer n8n auf einer Version älter als 1.121.0 betreibt, gibt einem nicht authentifizierten Angreifer die Möglichkeit, die Datenbank auszulesen, eine Admin-Sitzung zu fälschen und beliebige Befehle auf dem Server auszuführen. Keine Zugangsdaten nötig. Keine Benutzerinteraktion erforderlich. CVSS 10.0. Zwischen dem 19. Dezember 2025 und dem 7. Februar 2026 hat n8n mindestens acht kritische und hochschwere Sicherheitslücken offengelegt: unauthentifizierte Remote Code Execution, Sandbox-Escapes und Expression-Injection-Bugs, die vorherige Patches umgehen. GreyNoise protokollierte 33.000 Exploit-Versuche gegen exponierte n8n-Instanzen in einer einzigen Woche.
Das ist kein theoretisches Risiko. Das ist eine aktive Angriffsfläche.
Die CVE-Zeitleiste: Acht Schwachstellen, sechs Wochen
Die Schwachstellen kamen in drei Wellen. Jede war schlimmer als die vorherige.
Welle 1: Expression-Injection und Sandbox-Escapes (Dezember 2025)
CVE-2025-68613 (CVSS 8.8) wurde am 19. Dezember 2025 veröffentlicht. Ein authentifizierter Benutzer konnte über n8ns Expression-Sprache beliebige Systembefehle einschleusen. Der Expression-Evaluator, der Template-Variablen wie {{ $json.email }} in Workflow-Knoten verarbeitet, hat Eingaben mit JavaScript-Code nicht ordnungsgemäß bereinigt. Ein Angreifer mit Workflow-Bearbeitungsrechten konnte Ausdrücke schreiben, die aus der Sandbox des Evaluators ausbrachen und Shell-Befehle auf dem Host ausführten. Behoben in n8n 1.20.4.
CVE-2025-68668 (CVSS 9.9), veröffentlicht am 26. Dezember, erhielt den Codenamen “N8scape.” n8n 1.0 führte Python-Code-Ausführung über Pyodide ein, eine WebAssembly-basierte Python-Laufzeitumgebung, die in einer Sandbox läuft. N8scape zeigte, dass die Sandbox-Grenze durchlässig war: Ein gezielt konstruierter Python-Payload konnte Pyodides Isolation verlassen und auf das Host-Dateisystem, Umgebungsvariablen und das Netzwerk zugreifen. Der Angriff erforderte Authentifizierung, aber nur grundlegende Workflow-Erstellungsrechte.
CVE-2025-68697 (CVSS 5.4) erschien am selben Tag. n8ns veralteter JavaScript-Ausführungsmodus, der in älteren Workflows zum Einsatz kommt, erlaubte beliebige Datei-Lese- und Schreiboperationen. Niedrigerer Schweregrad, aber ein weiterer Pfad zur Datenexfiltration für authentifizierte Angreifer.
Welle 2: Ni8mare, die CVSS 10.0 (Januar 2026)
CVE-2026-21858 (CVSS 10.0) ist die Schwachstelle, die Self-Hosted-n8n-Betreibern den Schlaf rauben sollte. Entdeckt von Dor Attias bei Cyera Research Labs und mit dem Codenamen “Ni8mare” versehen, erfordert diese Schwachstelle keinerlei Authentifizierung. Jede n8n-Instanz mit einem exponierten Form- oder Webhook-Trigger ist verwundbar.
Der Angriff nutzt eine Content-Type-Confusion-Schwachstelle aus. Wenn ein Webhook-Endpunkt einen Multipart-Datei-Upload erwartet, parst n8ns Middleware den Request-Body über Formidable und füllt req.body.files mit bereinigten temporären Dateipfaden. Sendet der Angreifer den Request aber mit Content-Type: application/json, läuft stattdessen der JSON-Body-Parser. Die Funktion prepareFormReturnItem() prüft nie, welcher Parser tatsächlich ausgeführt wurde. Sie vertraut blind dem Inhalt von req.body.files, einschließlich vom Angreifer kontrollierter filepath-Werte, die auf /home/node/.n8n/database.sqlite zeigen.
Die vollständige Angriffskette funktioniert in drei Stufen:
- Beliebiges Dateilesen: Ein JSON-Payload mit einem manipulierten
files-Objekt senden, dessenfilepathauf die SQLite-Datenbank zeigt. n8n liefert pflichtgemäß den Dateiinhalt zurück. - Authentifizierungs-Bypass: Admin-Passwort-Hash und
ENCRYPTION_KEYaus der Datenbank und Konfiguration extrahieren. Ein gültiges JWT-Session-Cookie fälschen. - RCE: Einen Workflow mit einem “Execute Command”-Knoten erstellen. Beliebige Befehle ausführen.
Gemeldet am 9. November 2025. Gepatcht am 18. November 2025 (vor der öffentlichen Bekanntgabe). CVE zugewiesen am 6. Januar 2026. Öffentliche Bekanntgabe am 7. Januar 2026. Behoben in Version 1.121.0. Geschätzt waren 100.000 Instanzen potenziell betroffen.
CVE-2026-21877 (CVSS 9.9) erschien am selben Tag: Remote Code Execution über beliebige Dateischreiboperationen, betrifft Versionen 0.123.0 bis 1.121.3. Behoben in 1.121.3.
Welle 3: Der Patch-Bypass (Februar 2026)
Der Fix für CVE-2025-68613 verließ sich auf TypeScript-Typprüfungen, um sicherzustellen, dass Expression-Eingaben Strings sind, bevor sie bereinigt werden. Das reichte nicht.
CVE-2026-25049 (CVSS 9.4), veröffentlicht am 7. Februar, zeigte, dass die Bereinigungsprüfung umgangen werden konnte, indem Nicht-String-Werte (Objekte, Arrays oder Symbols) als Expression-Eingaben übergeben wurden. Wie Endor Labs Forscher Cris Staicu erklärte: “TypeScript kann diese Typprüfungen bei zur Laufzeit vom Angreifer erzeugten Werten nicht durchsetzen.” Ein authentifizierter Angreifer mit Workflow-Bearbeitungsrechten konnte erneut beliebige Systembefehle ausführen.
In Kombination mit einem öffentlichen Webhook wird der Angriff auch ohne Authentifizierung ausnutzbar. Behoben in den Versionen 1.123.17 und 2.5.2.
Elf weitere Schwachstellen wurden parallel zu CVE-2026-25049 veröffentlicht, darunter:
- CVE-2026-21893 (CVSS 9.4): Command-Injection über Admin-Berechtigungen
- CVE-2026-25052 (CVSS 9.4): TOCTOU-Schwachstelle beim Dateizugriff
- CVE-2026-25053 (CVSS 9.4): OS-Command-Injection im Git-Knoten
- CVE-2026-25051 (CVSS 8.5): XSS in Webhook-Antworten
- CVE-2026-25054 (CVSS 8.5): Persistentes XSS in der Markdown-Komponente
Warum n8ns Architektur das Problem verschärft
Das sind keine isolierten Bugs in Randfunktionen. Sie treffen den Kern dessen, was n8n tut: benutzerdefinierte Logik auf einem gemeinsam genutzten Server ausführen. Drei architektonische Muster verstärken das Risiko.
Expression-Evaluation ist eine verkappte Shell
n8ns Expression-Sprache ist im Kern JavaScript eval() mit Leitplanken. Benutzer schreiben {{ }}-Templates, die zur Laufzeit ausgewertet werden, um Daten zwischen Workflow-Knoten zu transformieren. Die Leitplanken (Sandbox-Grenzen, Typprüfungen, Bereinigung) wurden inzwischen dreimal umgangen (CVE-2025-68613, CVE-2026-25049 und CVE-2025-68668). Jeder Fix adressierte die spezifische Bypass-Technik, ohne das grundlegende Problem anzugehen: Vom Benutzer bereitgestellten Code in einer gemeinsamen Ausführungsumgebung sicher auszuführen, ist extrem schwierig. Der Pyodide-Sandbox-Escape bewies, dass selbst WebAssembly-Isolation kein Allheilmittel ist.
Webhooks schaffen unauthentifizierte Angriffsfläche
n8n-Workflows starten häufig mit Webhook-Triggern, die auf öffentlichen URLs lauschen. Diese Endpunkte sind konstruktionsbedingt unauthentifiziert: Sie akzeptieren eingehende HTTP-Anfragen von externen Systemen. Ni8mare (CVE-2026-21858) hat genau dieses Muster ausgenutzt. Jeder Workflow mit einem Form- oder Webhook-Trigger wurde zum Einstiegspunkt für eine vollständige Serverkompromittierung. Die n8n-Dokumentation empfiehlt, Webhooks hinter einen Reverse Proxy mit Authentifizierung zu stellen. Die Standardkonfiguration exponiert sie aber direkt.
Self-Hosted bedeutet Self-Patched
n8n-Cloud-Instanzen wurden vom n8n-Team gepatcht. Self-Hosted-Instanzen, die den Großteil der n8n-Deployments ausmachen, hängen davon ab, dass Betreiber manuell aktualisieren. Die Lücke zwischen “Patch verfügbar” und “Patch eingespielt” ist genau der Zeitraum, in dem die von GreyNoise protokollierten 33.000 Exploit-Versuche stattfanden. Viele Self-Hosted-n8n-Instanzen laufen auf Docker mit fixierten Version-Tags und erhalten daher nie automatische Updates.
Für Unternehmen im DACH-Raum kommt ein weiterer Aspekt hinzu: Wer personenbezogene Daten über n8n-Workflows verarbeitet und eine verwundbare Version betreibt, hat möglicherweise ein DSGVO-Problem. Eine aktiv ausgenutzte Schwachstelle, die Zugriff auf die gesamte Datenbank ermöglicht, ist ein meldepflichtiger Sicherheitsvorfall nach Art. 33 DSGVO, mit einer Frist von 72 Stunden.
Was Sie jetzt tun müssen
Wenn Sie n8n selbst hosten, ist das die Mindest-Maßnahmenliste.
Sofort patchen
Die sichere Mindestversion Stand Februar 2026 ist n8n 2.5.2 (oder 1.123.17 für den 1.x-Zweig). Das deckt alle bekannten CVEs ab, einschließlich CVE-2026-25049. Version prüfen:
n8n --version
# oder bei Docker:
docker exec n8n-container n8n --version
Wenn Sie auf einer älteren Version laufen, aktualisieren Sie jetzt. Nicht morgen. Jetzt.
Webhook-Zugriff einschränken
Stellen Sie Ihre n8n-Instanz hinter einen Reverse Proxy (Nginx, Caddy, Traefik), der für alle Endpunkte Authentifizierung verlangt, außer für die spezifischen Webhook-Pfade, die Ihre Integrationen benötigen. Blockieren Sie allen direkten Zugriff auf die n8n-Oberfläche und API aus dem öffentlichen Internet.
# Beispiel: n8n-Zugriff auf VPN/internes Netzwerk beschränken
server {
listen 443 ssl;
server_name n8n.ihrefirma.de;
# Webhook-Pfade von überall erlauben
location /webhook/ {
proxy_pass http://localhost:5678;
}
# Alles andere nur über VPN/interne IP
location / {
allow 10.0.0.0/8;
deny all;
proxy_pass http://localhost:5678;
}
}
Workflow-Berechtigungen prüfen
n8n bietet rollenbasierte Zugriffskontrolle in seinen kostenpflichtigen Tarifen. In der Community Edition kann jeder Benutzer mit Zugang Workflows mit Execute-Command-Knoten erstellen. Beschränken Sie den Zugriff auf Ihre n8n-Instanz auf Personen, die ihn tatsächlich brauchen.
Auf Exploitation überwachen
Prüfen Sie Ihre n8n-Logs auf verdächtige Webhook-Anfragen, insbesondere:
- Anfragen an Webhook-Endpunkte mit
Content-Type: application/json, diefilepath- oderfiles-Schlüssel im Body enthalten - Workflows mit Execute-Command-Knoten, die Sie nicht erstellt haben
- Ungewöhnliche ausgehende Netzwerkverbindungen vom n8n-Container
Deployment-Modell überdenken
Wenn Sie n8n für KI-Workflow-Automatisierung mit Zugriff auf sensible Zugangsdaten (API-Keys, Datenbankverbindungen, OAuth-Tokens) betreiben, sollten Sie prüfen, ob Self-Hosting noch die richtige Wahl ist. n8n Cloud übernimmt das Patching automatisch. Der Kompromiss ist Kontrolle vs. Sicherheitswartungsaufwand.
Das größere Bild: Workflow-Plattformen als Angriffsziele
n8n ist nicht einzigartig unsicher. Es ist einzigartig populär, Open Source und wird häufig selbst gehostet, was es zu einem attraktiveren Ziel macht. Schwachstellen werden gefunden und öffentlich bekannt gegeben. Geschlossene Plattformen wie Zapier und Make haben eigene Sicherheitsrisiken, aber deren Angriffsfläche wird vom Anbieter verwaltet, nicht von jedem einzelnen Betreiber.
Das Muster ist hier wichtiger als die spezifischen CVEs. Workflow-Automatisierungsplattformen werden zum Bindegewebe von KI-Systemen in Unternehmen. Sie speichern API-Schlüssel für dutzende Dienste, verarbeiten sensible Kundendaten und orchestrieren zunehmend KI-Agenten-Aktionen. Wenn eine Workflow-Plattform kompromittiert wird, erstreckt sich der Schaden auf jedes verbundene System.
Die OWASP Top 10 für LLM-Anwendungen warnen bereits vor unsicherem Plugin-Design und übermäßiger Handlungsautonomie. n8ns CVE-Cluster ist das, wie diese Warnungen in der Praxis aussehen: Eine Plattform mit breitem Systemzugriff, die benutzerdefinierten Code ausführt, exponiert ins Internet.
Patchen Sie Ihre Instanzen. Sichern Sie Ihre Webhooks ab. Und behandeln Sie Ihre Workflow-Automatisierungsplattform mit derselben Sicherheitsrigorosität, die Sie auf Ihre Produktionsdatenbank anwenden. Denn sie hat wahrscheinlich die Zugangsdaten, um darauf zuzugreifen.
Häufig gestellte Fragen
Was ist CVE-2026-21858 (Ni8mare) und warum ist es so kritisch?
CVE-2026-21858 ist eine unauthentifizierte Remote-Code-Execution-Schwachstelle in n8n mit einem CVSS-Score von 10.0, dem maximal möglichen Wert. Sie nutzt eine Content-Type-Confusion-Schwachstelle in Webhook-Handlern aus, um beliebige Dateien vom Server zu lesen, Admin-Zugangsdaten zu extrahieren, Session-Tokens zu fälschen und Systembefehle auszuführen. Kein Login erforderlich. Jede n8n-Instanz mit einem exponierten Form- oder Webhook-Trigger ist verwundbar. Betroffen sind die Versionen 1.65.0 bis 1.120.4. Behoben in Version 1.121.0.
Welche ist die sichere Mindestversion von n8n im Februar 2026?
Die sichere Mindestversion ist n8n 2.5.2 (oder 1.123.17 für den 1.x-Zweig). Diese Version enthält Patches für alle bekannten kritischen CVEs, einschließlich CVE-2026-21858 (Ni8mare, CVSS 10.0), CVE-2026-25049 (Expression-Escape, CVSS 9.4) und CVE-2026-21877 (beliebige Dateischreiboperationen, CVSS 9.9).
Wie viele CVEs wurden gegen n8n Ende 2025 und Anfang 2026 offengelegt?
Mindestens acht kritische und hochschwere CVEs wurden zwischen dem 19. Dezember 2025 und dem 7. Februar 2026 offengelegt. Darunter drei Expression-Injection- und Sandbox-Escape-Schwachstellen, zwei unauthentifizierte RCE-Bugs (einschließlich der CVSS 10.0 Ni8mare) sowie mehrere Command-Injection- und XSS-Schwachstellen. Im Februar-2026-Batch wurden elf weitere Schwachstellen veröffentlicht.
Ist n8n Cloud von diesen Schwachstellen betroffen?
n8n-Cloud-Instanzen wurden vom n8n-Team gepatcht, sobald Fixes verfügbar waren, und sind daher nicht mehr verwundbar. Self-Hosted-n8n-Instanzen sind dagegen darauf angewiesen, dass Betreiber manuell auf die gepatchten Versionen aktualisieren. Die Mehrheit der in freier Wildbahn beobachteten Exploit-Versuche richtete sich gegen Self-Hosted-Instanzen, die noch nicht aktualisiert waren.
Ist die Ausnutzung einer n8n-Schwachstelle ein DSGVO-meldepflichtiger Vorfall?
Ja, potenziell. Wenn über eine n8n-Instanz personenbezogene Daten verarbeitet werden und ein Angreifer über CVE-2026-21858 Zugriff auf die Datenbank erlangt, liegt ein Sicherheitsvorfall nach Art. 33 DSGVO vor. Dieser muss innerhalb von 72 Stunden der zuständigen Aufsichtsbehörde gemeldet werden. Unternehmen im DACH-Raum sollten ihre n8n-Deployments daher umgehend auf verwundbare Versionen prüfen.