Kritische RCE-Sicherheitslücken in n8n: Vollständige Übernahme der Low-Code-AI-Plattform als neues Supply-Chain-Risiko

n8n, eine der meistgenutzten Open-Source-Plattformen für Workflow-Automatisierung und Low-Code-AI-Orchestrierung, steht seit Ende Dezember 2025 im Zentrum einer ganzen Welle kritischer Remote-Code-Execution-(RCE-)Lücken. Innerhalb von knapp zwei Wochen wurden mehrere Schwachstellen mit CVSS-Scores bis 10.0 veröffentlicht, die eine vollständige Kompromittierung von n8n-Instanzen ermöglichen – teilweise sogar ohne Authentifizierung.

Für Unternehmen, die n8n als Drehkreuz für API-Integrationen, Datenpipelines, KI-Agenten und LLM-Aufrufe nutzen, ist das mehr als ein isoliertes Produktproblem. n8n wird damit selbst zum potenziellen Supply-Chain-Angreifer: Ein übernommener n8n-Server kann Aktionen in Dutzenden SaaS-Systemen ausführen, sensible Daten exfiltrieren und AI-Modelle gezielt manipulieren.

Dieser Beitrag ordnet die aktuellen Funde ein, erklärt die Besonderheiten für AI-Orchestrierung und zeigt konkrete Handlungsoptionen für Unternehmen.

---

Kontext: Was ist passiert und welche Schwachstellen betreffen n8n?

n8n als kritische Infrastruktur für Automatisierung und KI

n8n ist eine modulare Automationsplattform, die Workflows zwischen SaaS-Diensten, Datenbanken, internen APIs und KI-Diensten (z. B. OpenAI, Azure OpenAI, lokale LLMs) orchestriert. In vielen Architekturen fungiert n8n als:

• zentraler Ausführungsknoten für Integrationen und Hintergrundjobs,

• Credential-Tresor für API-Schlüssel und OAuth-Tokens,

• Steuerungsebene für KI-Agenten und komplexe LLM-Workflows.

Damit wird n8n – funktional ähnlich wie iPaaS- oder M2M-Integrationsplattformen – zur hochsensiblen Komponente: Ein Angreifer mit Kontrolle über n8n erbt praktisch den Zugriff auf alle angebundenen Systeme.

Die aktuelle RCE-Welle: mehrere kritische CVEs in kurzer Zeit

In den letzten Tagen wurden gleich mehrere kritische Schwachstellen in n8n bekannt, die allesamt Remote Code Execution ermöglichen und überwiegend bereits gepatcht sind:

• CVE-2025-68613 (CVSS 9.9) – RCE über das Workflow-Expression-System. Authentifizierte Nutzer können die JavaScript-Sandbox verlassen und Code im Kontext des n8n-Prozesses ausführen. Dies ermöglicht vollständige Übernahme der Instanz einschließlich Zugriff auf gespeicherte Zugangsdaten und interne Netzwerke.

• CVE-2025-68668 („N8scape“, CVSS 9.9) – Sandbox-Bypass in der Python Code Node (Pyodide). Authentifizierte Nutzer mit Workflow-Erstell- oder Änderungsrechten können beliebige Systembefehle ausführen.

• CVE-2026-21877 (CVSS 10.0) – Upload von Dateien gefährlichen Typs / unzureichend kontrollierte Code-Ressourcen. Unter bestimmten Bedingungen können authentifizierte Angreifer über hochgeladene Inhalte beliebigen Code über den n8n-Service ausführen.

• CVE-2026-21858 („Ni8mare“, CVSS 10.0) – Content-Type-Confusion in Webhook- und Formular-Endpunkten. Speziell gestaltete HTTP-Anfragen erlauben zunächst das Auslesen sensibler Dateien (inkl. Secrets) und anschließend, über gefälschte Admin-Sessions und Pfadmanipulation, die vollständige Übernahme der Instanz – ohne Authentifizierung.

Gemeinsam ist allen Schwachstellen:

1. Sie erlauben direkte Ausführung von Code oder Befehlen mit den Rechten des n8n-Prozesses.

2. Sie führen im Erfolgsfall zur kompletten Kompromittierung der n8n-Instanz.

3. Über n8n werden anschließend verbundene Systeme angreifbar (Supply-Chain-Effekt).

Betroffene Versionen und Patch-Status (vereinfachte Übersicht)

Die Details variieren je CVE; in der Breite gilt jedoch:

• Ältere 1.x-Versionen sind von RCE-Lücken im Expression-System und in Code-Nodes betroffen (CVE-2025-68613, CVE-2025-68668, CVE-2026-21877).

• Versionen bis einschließlich 1.65.0 waren insbesondere für den „Ni8mare“-Bug anfällig, der in späteren Releases (u. a. 1.121.0 und folgende Sicherheitsreleases) behoben wurde.

• Neuere 1.120.x- und 1.121.x-Releases adressieren einzelne Schwachstellen, erfordern aber präzises Version-Management, da Fixes gestaffelt ausgeliefert wurden.

• 2.x-Linie: Nach aktuellem Stand sind die bekannten kritischen RCEs in stabilen 2.x-Releases adressiert, allerdings gilt: Nur das _jeweils aktuellste_ Release bietet den vollständigen Fix-Stand.

Unternehmen sollten daher nicht pauschal „auf 2.x“ vertrauen, sondern die exakten Versionshinweise und Security Advisories des Projekts gegen die produktiv eingesetzten Builds prüfen.

---

Detaillierte Analyse: Warum die n8n-RCE-Lücken so gravierend sind

1. Angriffspfad: Von n8n zum gesamten Unternehmens-Stack

n8n speichert typischerweise:

• API-Schlüssel und Tokens für SaaS-Dienste (CRM, ERP, Collaboration, Ticketing usw.),

• Datenbank-Credentials für produktive Systeme,

• Secrets für interne APIs und Microservices,

• Zugriffsdaten für E-Mail- und Notification-Dienste,

• Konfigurationsdaten für AI-Workflows (z. B. Systemprompts, Model-Endpunkte, Routing-Logik).

Ein erfolgreicher RCE-Angriff bedeutet damit:

1. Server-Kompromittierung – Shell-Zugriff, Installation von Backdoors, Manipulation von Logs.

2. Credential-Diebstahl – Auslesen sämtlicher im n8n Credential Store abgelegter Secrets.

3. Lateral Movement – Verwendung der Credentials, um auf Datenbanken, interne Services und SaaS-Konten zuzugreifen.

4. Persistente Manipulation – Änderung oder Anlegen neuer Workflows, die dauerhaft Daten absaugen oder Aktionen auslösen.

Gerade in AI-Szenarien kann ein Angreifer damit:

• Modelle mit manipulierten Prompts und Kontextdaten füttern,

• vertrauliche Trainings- oder Inferenzdaten ins Externe exfiltrieren,

• im Namen von Nutzern z. B. Tickets erstellen, Mails versenden oder Dateien verschieben,

• „leise“ spätere Schritte für eine zweite Angriffswelle vorbereiten.

2. Authentifiziert vs. nicht authentifiziert: Warum „interne“ n8n-Instanzen nicht automatisch sicher sind

Ein Teil der Schwachstellen erfordert prinzipiell einen authentifizierten Nutzer mit bestimmten Rechten (z. B. Workflow-Erstellung). Das relativiert das Risiko nur auf den ersten Blick:

• In vielen Unternehmen existieren breit vergebene n8n-Accounts für Fachbereiche („Citizen Developer“).

• n8n-Instanzen sind oft über VPN, SSO oder sogar direkt im Firmen-LAN erreichbar.

• Die Übergänge zwischen „intern“ und „extern“ sind durch Remote Work, Partnerzugänge und Cloud-VPNs weich geworden.

Kompromittierte Endgeräte oder geleakte Zugangsdaten genügen dann, um die RCE-Lücken auszunutzen. Besonders kritisch ist „Ni8mare“ (CVE-2026-21858), weil hier gar keine Authentifizierung nötig ist, sofern Webhook- oder Form-Endpunkte von außen erreichbar sind.

3. Low-Code-AI als Multiplikator: Wenn der Orchestrator zum Angreifer wird

Unternehmen nutzen n8n zunehmend als Steuerungsschicht für:

• Agent-basierte KI-Workflows (z. B. Recherche- oder Support-Agenten),

• LLM-Pipelines mit Retrieval-Augmented Generation (RAG),

• automatisierte Decision-Flows (Freigaben, Einstufungen, Scoring),

• Datenanreicherungen durch externe APIs.

Wird diese Schicht kompromittiert, ergeben sich besondere Risiken:

• Datenexfiltration im Kontext: Angreifer können gezielt jene Daten exportieren, die über AI-Workflows laufen (z. B. Kundendialoge, interne Wissensdatenbanken, vertrauliche Dokumente).

• Still manipulierte Modelle: Systemprompts und Routing-Logik können unauffällig geändert werden, sodass Modelle systematisch „falsche“ Entscheidungen treffen oder schleichend Informationen preisgeben.

• Missbrauch von Agentenfähigkeiten: KI-Agenten werden u. U. genutzt, um Systeme zu durchsuchen oder Transaktionen anzustoßen. Ein Angreifer kann diese Fähigkeiten für seine Zwecke umbiegen.

Damit ist die n8n-Problematik mehr als ein klassischer „Server ist verwundbar“-Fall: Sie betrifft die Integrität ganzer AI-gestützter Geschäftsprozesse.

---

Praxisnahe Szenarien: Wie ein Angriff über n8n konkret aussehen kann

Beispiel 1: Übernahme eines AI-Support-Workflows im SaaS-Startup

Ein SaaS-Anbieter betreibt n8n in der Cloud, um:

• Support-Tickets aus E-Mails und Chatbots zu erzeugen,

• LLM-basierte Antwortvorschläge zu generieren,

• Kundendaten aus CRM und Billing-System zu aggregieren.

Ein Angreifer findet einen öffentlich erreichbaren n8n-Formular-Webhook, der verwundbar für „Ni8mare“ ist. Nach erfolgreicher Ausnutzung:

1. Liest er Konfigurationsdateien und `config.json`/Credential-Stores aus.

2. Extrahiert er API-Tokens für CRM, Support-Tool und LLM-Anbieter.

3. Legt er einen unscheinbaren Workflow an, der alle neuen Supportanfragen und relevanten Kundendaten in ein externes System spiegelt.

4. Verwendet er das CRM-Token, um selektiv „wertvolle“ Kunden zu identifizieren und gezielte Phishing-Mails zu generieren.

Der Angriff bleibt u. U. über Wochen unbemerkt, weil die n8n-Instanz weiterhin ordnungsgemäß arbeitet.

Beispiel 2: Interner n8n-Server als Sprungbrett ins OT-Netz eines Industrieunternehmens

Ein Industrieunternehmen nutzt n8n on-premises, um:

• Zustandsdaten von Produktionsanlagen zu sammeln,

• Meldungen in ein Ticket-System zu pushen,

• Reports mit Hilfe eines LLM aus Messwerten zu generieren.

Die n8n-Instanz ist nur per VPN zugänglich, viele Ingenieure und Dienstleister besitzen Accounts. Ein kompromittiertes Dienstleister-Notebook erlaubt einem Angreifer, sich in n8n einzuloggen und eine der authentifizierten RCE-Lücken zu nutzen:

1. Der Angreifer installiert einen Reverse Shell-Listener auf dem n8n-Host.

2. Er greift auf interne Datenbanken zu, in denen OT-Zugangsdaten gespeichert sind.

3. Über bestehende n8n-Flows erweitert er den Zugriff auf weitere interne Dienste.

4. Er schaltet zusätzliche „Diagnose-Workflows“ frei, die in Wahrheit Daten abziehen.

So wird n8n zum bequemen Einstiegspunkt in Segmenten, die eigentlich nur indirekt erreichbar sind.

Beispiel 3: Manipulation eines KI-Freigabeprozesses im Finanzbereich

Ein Finanzdienstleister hat n8n hinter einem API-Gateway im Einsatz, um mittels LLM automatische Risikobewertungen für kleinere Transaktionen vorzunehmen. Das Ergebnis des Modells fließt in einen Freigabeprozess ein.

Ein interner Angreifer mit n8n-Account nutzt eine authentifizierte RCE-Lücke, um:

• Systemprompts zu verändern,

• Schwellenwerte für „Low Risk“ abzusenken,

• zusätzliche Ausnahmen hinzuzufügen.

Der Prozess bleibt formal intakt, generiert aber systematisch zu positive Bewertungen. Das Risiko liegt hier weniger im Datenabfluss als in der schleichenden Verzerrung von Entscheidungen.

---

Business-Relevanz: Was Unternehmen jetzt konkret tun sollten

1. Sofortmaßnahmen (innerhalb der nächsten 24–72 Stunden)

1. Version prüfen und patchen

- Exakte n8n-Versionen aller Instanzen erfassen (Produktiv, Staging, Dev).

- Gegen die offiziellen Security Advisories und CVEs abgleichen.

- Schnellstmöglich auf eine Version aktualisieren, die alle bekannten RCEs schließt (in der Regel: aktuellste stabile Hauptversion).

1. Angriffsfläche reduzieren

- n8n-Instanzen nicht direkt aus dem Internet exponieren.

- Webhook- und Formular-Endpunkte

- hinter API-Gateways legen,

- IP-basiert oder per mTLS/Token schützen,

- nur für wirklich benötigte Services freigeben.

1. Zugang stark einschränken

- Rollen und Berechtigungen überprüfen:

- Nur vertrauenswürdige Nutzer erhalten Rechte zur Workflow-Erstellung/-Änderung.

- Service-Accounts minimieren und mit least privilege ausstatten.

- SSO, MFA und strenge Passwortregeln für n8n-Zugänge erzwingen.

1. Credential-Risiko adressieren

- Alle über n8n gespeicherten Secrets inventarisieren.

- Bei Verdacht auf Kompromittierung: API-Keys, Tokens und Passwörter rotationsbasiert erneuern.

1. Logging und erste Forensik

- Logs der letzten Wochen sichern (Webserver, n8n, Reverse Proxy).

- Nach ungewöhnlichen Workflows, neuen Credentials und externen Call-Zielen suchen.

2. Mittelfristige Maßnahmen (2–8 Wochen)

1. Architektur-Review für AI-Orchestrierung

- n8n als hochkritischen Asset-Typ einstufen (ähnlich wie CI/CD-Systeme).

- Trennung von:

- produktiver Orchestrierung (Produktiv-Daten, Live-Workflows),

- experimenteller Umgebung für Citizen Developer und PoCs.

1. Netzwerk- und Segmentierungskonzept anpassen

- n8n in ein besonders gehärtetes Segment verschieben (Restricted Zone).

- Nur strikt notwendige ein- und ausgehende Verbindungen zulassen.

- Separate n8n-Instanzen für stark unterschiedliche Domains (z. B. HR-Daten vs. Marketing-Automation).

1. Security-Governance für Low-Code- und AI-Plattformen etablieren

- Klare Policies, welche Daten über n8n verarbeitet werden dürfen.

- Klassifizierungsregeln: Besonders schützenswerte Daten (z. B. Gesundheits-, Gehaltsdaten) nur in streng kontrollierten Workflows.

- Technische „Guardrails“:

- genehmigte Node-Typen und Integrationen,

- Code-Nodes (JavaScript/Python) nur für spezialisierte Teams freigeben.

1. Monitoring und Detektion aufrüsten

- Security-Tools (SIEM/XDR) so konfigurieren, dass:

- Anomalien bei n8n-Prozessaktivität,

- ungewöhnliche ausgehende Verbindungen,

- Massenänderungen an Workflows erkannt werden.

- Alerts für:

- neue Admin-Benutzer,

- Änderungen an Credentials,

- neue, externe HTTP-Targets in Workflows.

3. Langfristige Strategie: n8n und ähnliche Plattformen wie kritische Supply-Chain-Komponenten behandeln

1. Threat Modeling für Automations-Stack

- n8n, CI/CD, IaC-Pipelines, AI-Orchestrierung und Secrets-Management gemeinsam betrachten.

- Angreiferpfade modellieren: „Wenn n8n fällt, welche Systeme fallen mit?“

1. Zero-Trust-Prinzipien auch für interne Orchestratoren anwenden

- Kein implizites Vertrauen, nur weil ein Dienst „intern“ ist.

- Durchgängige Authentifizierung, Authorisierung und Verschlüsselung.

1. Vendor- und Open-Source-Risikomanagement

- Security-Advisories von n8n aktiv abonnieren und in den Patch-Prozess integrieren.

- Regelmäßige Penetrationstests, die n8n explizit einschließen.

1. Schulung von Citizen Developern und AI-Teams

- Sensibilisierung, dass Workflows Sicherheitsgrenzen verschieben können.

- Best Practices für sichere API-Nutzung, Datenminimierung und Secrets-Handling.

---

Fazit und wichtigste Takeaways für Entscheidungsträger

Die aktuelle RCE-Welle in n8n zeigt, wie schnell sich ein leistungsfähiger Orchestrator in ein systemisches Risiko verwandeln kann – insbesondere, wenn er im Zentrum von AI- und Automationsarchitekturen steht. Unternehmen müssen n8n und ähnliche Low-Code-Automationsplattformen als hochkritische Infrastruktur behandeln und entsprechend schützen.

Kernpunkte, die Sie mitnehmen sollten:

• Kritische RCE-Schwachstellen in n8n erlauben unter bestimmten Bedingungen die vollständige Übernahme von Instanzen – teilweise ohne Authentifizierung.

• Aufgrund der zentralen Rolle von n8n in Automations- und AI-Workflows wird jede Kompromittierung sofort zum Supply-Chain-Risiko für angebundene SaaS-Dienste, Datenbanken und interne Systeme.

• Kurzfristig sind Version-Checks, rasches Patchen, das Reduzieren der Exposition (insbesondere Webhooks/Formulare) und eine Überprüfung der Credentials zwingend notwendig.

• Mittelfristig sollten Unternehmen die Architektur ihrer AI- und Automations-Orchestrierung überarbeiten, n8n strikt segmentieren und Berechtigungen deutlich strenger fassen.

• Langfristig ist ein Sicherheitsmodell nötig, das Orchestratoren wie n8n als kritische Komponenten im Gesamtsystem betrachtet – inklusive Threat Modeling, Zero Trust und kontinuierlichem Monitoring.

• Wer frühzeitig reagiert, kann n8n weiterhin als leistungsstarke Low-Code-AI-Plattform nutzen – aber nur mit einem Security-Niveau, das seiner tatsächlichen Kritikalität entspricht.

Häufig gestellte Fragen (FAQ)

Was sind die aktuellen RCE-Sicherheitslücken in n8n und warum gelten sie als kritisch?

Die aktuellen Remote-Code-Execution-Schwachstellen in n8n (u. a. CVEs mit CVSS bis 10.0) ermöglichen es Angreifern, beliebigen Code im Kontext der n8n-Instanz auszuführen. Dadurch können sie den Server vollständig übernehmen, auf gespeicherte Zugangsdaten zugreifen und verbundene Systeme wie SaaS-Dienste, Datenbanken und KI-Workflows kompromittieren.

Wie funktionieren Angriffe über n8n konkret und welche Systeme sind betroffen?

Ein erfolgreicher Angriff beginnt meist mit der Ausnutzung einer RCE-Lücke in n8n, oft über Webhooks, Formular-Endpunkte oder Code-Nodes. Danach kann der Angreifer Credentials auslesen, Workflows manipulieren und über die angebundenen Integrationen auf CRM-, ERP-, Ticketing- oder KI-Systeme zugreifen und dort Daten abziehen oder Aktionen ausführen.

Welche besonderen Risiken entstehen durch die n8n-Lücken im Kontext von KI- und LLM-Workflows?

Da n8n häufig als Orchestrator für LLM-Aufrufe, KI-Agenten und RAG-Pipelines dient, gefährdet eine Kompromittierung die Vertraulichkeit und Integrität dieser Prozesse. Angreifer können Systemprompts verändern, Modelle gezielt mit manipulierten Kontextdaten steuern und vertrauliche Inhalte, die durch KI-Workflows laufen, im Hintergrund exfiltrieren.

Sind interne oder nur extern erreichbare n8n-Instanzen von den Schwachstellen betroffen?

Betroffen sind sowohl intern betriebene als auch öffentlich erreichbare n8n-Instanzen. Während einige Lücken authentifizierte Zugriffe voraussetzen, gibt es mit „Ni8mare“ (CVE-2026-21858) eine Schwachstelle, die bei erreichbaren Webhook- oder Formular-Endpunkten auch ohne Authentifizierung ausnutzbar ist, sodass selbst „nur intern“ gedachte Setups kritisch sein können.

Wie unterscheidet sich das Risiko von n8n von klassischen Einzelanwendungen im Unternehmen?

Im Gegensatz zu einer isolierten Anwendung fungiert n8n als zentraler Orchestrator und Credential-Tresor für zahlreiche Systeme. Wird n8n kompromittiert, vererbt sich der Zugriff auf viele angebundene Dienste weiter, wodurch ein einzelner Exploit sofort zum Supply-Chain-Risiko für den gesamten Automations- und KI-Stack wird.

Welche Sofortmaßnahmen sollten Unternehmen angesichts der n8n-RCE-Lücken ergreifen?

Unternehmen sollten kurzfristig alle produktiven, Staging- und Dev-Instanzen inventarisieren, gegen die offiziellen Security-Advisories abgleichen und auf das jeweils aktuellste sichere Release aktualisieren. Zusätzlich sollten Webhooks und Form-Endpunkte hinter Gateways gelegt, der direkte Internetzugang eingeschränkt, Berechtigungen reduziert, gespeicherte Secrets bei Verdacht rotiert und Logs auf Anomalien geprüft werden.

Wie können Unternehmen n8n langfristig sicher betreiben und Supply-Chain-Risiken minimieren?

Langfristig sollten Unternehmen n8n als hochkritische Infrastruktur einstufen, streng segmentieren und nach Zero-Trust-Prinzipien absichern. Dazu gehören ein dediziertes Architektur- und Threat-Modeling für den Automations- und KI-Stack, regelmäßige Penetrationstests, klar definierte Policies für Daten und Workflows sowie Schulungen für Citizen Developer und AI-Teams zu sicheren Integrations- und Secrets-Praktiken.