Wie die „Ni8mare“-Lücke 100.000 Server für eine vollständige Übernahme öffnete

Unternehmen und Produkt

n8n ist eine in Berlin ansässige Low-Code-Plattform für Workflow-Automatisierung, die es technischen und nicht-technischen Nutzern ermöglicht, verschiedene SaaS-Anwendungen, APIs und interne Datenbanken zu verbinden. Im Gegensatz zu vielen Mitbewerbern bietet n8n eine selbstgehostete Version an, was sie zu einer beliebten Wahl für Unternehmen macht, die hohen Wert auf Datenschutz und die Integration interner IT-Infrastruktur legen.

‍

Die Plattform ist hochgradig erweiterbar, unterstützt über 400 Integrationen und erlaubt die Ausführung von benutzerdefiniertem JavaScript- oder Python-Code. Da n8n-Instanzen oft weitreichenden Zugriff auf interne Systeme, Anmeldedaten und sensible Token haben, stellen sie ein hochgradiges Ziel für Angreifer dar, die sich lateral innerhalb eines Unternehmensnetzwerks bewegen möchten.

Was passiert ist

Die Schwachstelle konzentrierte sich auf eine Middleware-Funktion namens parseRequestBody(). Diese Funktion war für das Parsen eingehender HTTP-Anfragen für Webhooks und Form-Trigger verantwortlich. Unter bestimmten Bedingungen validierte die Middleware den „Content-Type“-Header nicht korrekt, was zu einer „Content-Type Confusion“ führte.

‍

Ein Angreifer konnte eine bösartige Anfrage konstruieren, die den Parser dazu brachte, interne Dateireferenzen (req.body.files) zu überschreiben. Dies ermöglichte ein primitives Auslesen beliebiger Dateien ohne Authentifizierung. Angreifer konnten dies nutzen, um die lokale SQLite-Datenbank und die Konfigurationsdatei zu exfiltrieren, welche das Verschlüsselungsgeheimnis für das Signieren von Session-Cookies enthielt.

‍

Sobald das Geheimnis erlangt wurde, konnte der Angreifer ein gültiges Administrator-Session-Cookie fälschen und somit sämtliche Authentifizierungen umgehen. Von dort aus war es möglich, einen neuen Workflow mit einem „Execute Command“-Node zu erstellen, um beliebige OS-Befehle auf dem zugrunde liegenden Server auszuführen. Da weltweit schätzweise 100.000 Server exponiert waren, war das Potenzial für eine massenhafte Ausnutzung signifikant.

Timeline

• 9. November 2025: Die Schwachstelle (CVE-2026-21858) wurde entdeckt und verantwortungsbewusst durch Dor Attias von Cyera Research Labs an n8n gemeldet.
• 18. November 2025: n8n veröffentlicht Version 1.121.0, die den Fix für die unauthentifizierte RCE enthält. Cloud-Instanzen werden automatisch gepatcht.
• 8. Januar 2026: n8n veröffentlicht ein formelles Security Advisory und einen Blogpost, um selbstgehostete Nutzer zu alarmieren, die noch kein Upgrade durchgeführt hatten.

‍

Time to Detect (TTD): N/A (Entdeckung durch Sicherheitsforschung).

Time to Resolve (TTR): 9 Tage (Vom Erstbericht bis zur Veröffentlichung eines stabilen Patches).

Wer war betroffen?

Die Sicherheitslücke betraf  in erster Linie selbstgehostete Benutzer, die n8n-Versionen zwischen 1.65.0 und 1.120.4 einsetzten. Insbesondere waren Instanzen gefährdet, die einen aktiven Workflow mit einem „Form Submission“-Trigger und einem „Form Ending“-Node nutzten, der eine Binärdatei zurückgab. Kunden von n8n Cloud waren nicht betroffen, da das Plattformteam die verwalteten Instanzen unmittelbar nach der Entwicklung des Fixes im November 2025 gepatcht hatte.

Wie n8n reagierte

n8n folgte einem Prozess der verantwortungsvollen Offenlegung (Responsible Disclosure). Nach Erhalt des Berichts im November priorisierten sie einen Fix und veröffentlichten diesen diskret als Version 1.121.0. Die öffentliche Bekanntmachung wurde bewusst bis Januar 2026 verzögert, um eine „Pufferzeit“ zu schaffen. Dies ermöglichte es der Mehrheit der selbstgehosteten Benutzer, das Upgrade durchzuführen, bevor technische Details und Proof-of-Concept (PoC) öffentlich wurden.

‍

Zusätzlich stellte n8n eine Workflow-Vorlage bereit, die Nutzer auf ihren eigenen Instanzen ausführen konnten, um nach potenziell gefährdeten Konfigurationen zu suchen.

Wie n8n kommunizierte

Die Kommunikation war transparent, aber kontrolliert. Die Warnmeldung vom 8. Januar umriss klar die technische Natur der Schwachstelle, die betroffenen Versionen und die notwendigen Schritte zur Behebung. Durch die Koordination mit den Forschern von Cyera stellte n8n sicher, dass die vollständige technische Analyse von „Ni8mare“ erst veröffentlicht wurde, nachdem der Patch bereits seit mehreren Wochen verfügbar war. Dies reduzierte das Risiko einer massenhaften Ausnutzung durch „Script Kiddies“ am ersten Tag (Day Zero) erheblich.

Wichtige Erkenntnisse für andere Teams

• Strikte Input-Validierung: Vertrauen Sie niemals blind dem Content-Type-Header. Stellen Sie sicher, dass Ihre Request-Parser erwartete Formate erzwingen.
• Defense in Depth: Der „Execute Command“-Node in n8n ist mächtig, aber gefährlich. Organisationen sollten Umgebungsvariablen nutzen, um risikoreiche Nodes zu deaktivieren, wenn diese nicht zwingend erforderlich sind.
• Sitzungssicherheit: Vermeiden Sie es, sich allein auf ein einzelnes statisches Verschlüsselungsgeheimnis in einer Konfigurationsdatei zu verlassen. Erwägen Sie die Rotation von Secrets.
• Automatisierte Security-Scans: Bieten Sie automatisierte Tools oder „Health Check“-Workflows an, um Nutzern zu helfen, unsichere Muster in ihrer eigenen Logik zu identifizieren.

Zusammenfassung

n8n behob eine kritische unauthentifizierte RCE (CVE-2026-21858), die durch unzureichende Input-Validierung in der Webhook-Middleware verursacht wurde. Die „Ni8mare“-Lücke erlaubte es Angreifern, Dateien zu lesen, Admin-Sessions zu fälschen und Code auszuführen. Selbstgehostete Nutzer werden dringend gebeten, sofort auf Version 1.121.0 oder neuer zu aktualisieren.

Wie ilert helfen kann

Wenn kritische Sicherheitslücken wie „Ni8mare“ bekannt werden, zählt jede Sekunde. ilert unterstützt Teams bei der Bewältigung solcher Notfälle durch:

‍

• Warnmeldungen bei Sicherheitssignalen: Integration mit Intrusion Detection Systemen (IDS) oder Schwachstellenscannern, um Ihr Sicherheitsteam sofort zu alarmieren, sobald ein Exploit-Versuch erkannt wird.
• Transparenz im Bereitschaftsdienst: Sicherstellen, dass die richtigen Security-Ingenieure sofort via Voice, SMS oder Chat benachrichtigt werden, wenn eine SEV-1 Warnung veröffentlicht wird.
• Sichere Incident War Rooms: Bei sensiblen Sicherheitsvorfällen müssen technische Diskussionen privat bleiben. Mit ilert können Sie private Slack-Channels direkt aus dem Incident heraus erstellen. Dies stellt sicher, dass nur autorisiertes Personal Zugriff auf sensible Logs oder Details zur Schwachstelle hat.
• KI-gestützte Stakeholder-Kommunikation: Vertrauen während einer globalen Sicherheitswarnung basiert auf Transparenz. Die KI-gestützte Incident-Kommunikation von ilert kann sofort professionelle und präzise Updates für Ihre Statusseiten entwerfen.

‍