n8n CVE-2026-25049: Kritische Sicherheitslücke – Betroffenheit prüfen & patchen

In n8n ermöglicht die kritische Schwachstelle CVE-2026-25049 die Ausführung beliebiger Systembefehle über präparierte Workflows. Angreifer mit Zugriff auf die Workflow-Bearbeitung können den Host übernehmen und – in Verbindung mit weiteren 2026 bekannt gewordenen Lücken – auf gespeicherte Credentials zugreifen.

Dieser Beitrag ist für Teams gedacht, die schnell entscheiden müssen: Bin ich betroffen? Und falls ja: Was ist jetzt zu tun? Sie bekommen eine klare Betroffenheitsprüfung (Versionen, Checks), konkrete Patch-Schritte, Priorisierung und pragmatische Maßnahmen, wenn ein sofortiges Update nicht überall möglich ist.

Ausgangslage & Risiko

n8n ist eine weit verbreitete Workflow-Automatisierungsplattform (Self-Hosted oder Cloud). Workflows verbinden APIs, Datenbanken und Cloud-Dienste – inklusive gespeicherter Credentials. Eine kompromittierte Instanz bedeutet daher oft vollständige Serverübernahme plus Zugriff auf alle in Workflows hinterlegten Secrets.

Bei CVE-2026-25049 ist entscheidend: Nutzer mit Berechtigung zum Erstellen oder Bearbeiten von Workflows können – über präparierte Expressions/Parameter – die Sandbox umgehen und Systembefehle ausführen. Die Lücke setzt Authentifizierung voraus, kann aber mit anderen 2026 bekannt gewordenen Lücken (z. B. unauthenticated RCE CVE-2026-21858 „Ni8mare”) kombiniert werden.

Weitere n8n-Themen: Supply-Chain-Risiken bei n8n Community Nodes, Checkliste für sichere n8n Deployments.

Technische Details von CVE-2026-25049

Die Schwachstelle entsteht durch unzureichendes Escaping von Expressions in n8n-Workflows. Die Expression-Engine von n8n wertet Nutzereingaben in Workflow-Parametern aus; dabei wird an kritischen Stellen nicht zuverlässig zwischen vertrauenswürdigen Metadaten und nutzerkontrollierten Werten unterschieden. Angreifer können manipulierte Parameter in Workflow-Nodes einfügen und so die Sandbox umgehen – mit der Folge, dass beliebige Systemkommandos auf dem Host ausgeführt werden.

Angriffsvektor (n8n security issue / exploit): Ein authentifizierter Nutzer mit Berechtigung zum Erstellen oder Bearbeiten von Workflows fügt in einem Node gezielt konstruierte Expressions ein. Diese nutzen die fehlende oder fehlerhafte Bereinigung (Sanitization) aus – in der technischen Analyse wird u. a. eine Type-Confusion bei Property-Access-Keys beschrieben: Die Sanitization-Funktion erzwingt keine konsistente Laufzeitprüfung der Schlüssel, sodass Objektzugriffe in einen Kontext gelangen, in dem Code ausgeführt wird. Das Ergebnis ist Remote Code Execution (RCE) im Kontext des n8n-Prozesses und damit voller Zugriff auf Dateisystem, Credential-Speicher und alle angebundenen Dienste.

Für eine detaillierte n8n vulnerability analysis und die genaue Beschreibung der Fixes verweisen wir auf das offizielle GitHub Security Advisory (GHSA-6cqr-8cfr-67f8).

Bin ich betroffen? (Betroffenheitsprüfung)

Betroffene und gepatchte Versionen

Die folgenden Versionen sind von CVE-2026-25049 betroffen bzw. enthalten den Fix. n8n Cloud wird vom Anbieter gepatcht.

Wo läuft n8n bei uns?

Prüfen Sie alle selbst gehosteten n8n-Instanzen: eigene Server, Container, Kubernetes, Docker Compose, Managed-Container bei Cloud-Anbietern. Pro Instanz die genutzte n8n-Version ermitteln (siehe Abschnitt „Kommandos & Checks”).

n8n Cloud

n8n Cloud wird vom Anbieter mit Sicherheitsupdates versehen. Trotzdem: Release Notes und Security-Hinweise von n8n regelmäßig prüfen.

Kontext: Weitere n8n-CVEs 2026

Neben CVE-2026-25049 wurden 2026 u. a. CVE-2026-21858 (Ni8mare) (unauthenticated RCE), CVE-2026-21877 (Authenticated RCE, u. a. Git-Node), CVE-2026-27495 (Sandbox Escape) und Meldungen zu Credential-Exposure veröffentlicht. Alle zeitnah patchen.

Sofortmaßnahmen & Patch-Plan

Priorisierung nach Exponierung und Nutzung

Patchen „überall” ist das Ziel – die Reihenfolge reduziert Risiko:

• Stufe 1 (sofort): n8n-Instanzen mit Internet-Zugang oder mit vielen Nutzern mit Workflow-Edit-Rechten.
• Stufe 2 (zeitnah): Interne n8n-Instanzen mit Zugriff auf sensible APIs/Credentials.
• Stufe 3 (nachziehen): Reine Test-/Staging-Instanzen (mit festem Patch-Plan).

Patchen: Was konkret tun?

Auf 1.123.17 (1.x) bzw. 2.5.2 (2.x) oder höher aktualisieren. Je nach Deployment: Paket-Update, neues Docker-Image ziehen, Helm/Manifest anpassen und ausrollen. Nach dem Update Version erneut prüfen und ggf. Credentials rotieren, wenn Kompromittierung nicht ausgeschlossen werden kann.

Wenn Patch nicht sofort geht: kurzfristige Risikoreduktion

Workarounds ersetzen kein Patch – sie kaufen Zeit:

Kommandos & Checks

Check 1: n8n-Version in der Oberfläche oder per CLI.

# Version anzeigen (CLI, wenn n8n im PATH)
n8n --version

# Oder: In der n8n-Oberfläche unter Einstellungen / Settings die angezeigte Version prüfen.

Check 2: n8n in Docker – Version im Container prüfen.

# Container starten und Version auslesen
docker run --rm --entrypoint sh n8nio/n8n:latest -c "n8n --version" 2>/dev/null || true

# Eigenes Image: Tag prüfen und auf gepatchtes Image (z. B. 1.123.17 / 2.5.2+) wechseln
docker images | grep n8n

Check 3: npm/Node-basierte Installation (z. B. global installiert).

# Globale n8n-Installation
npm list -g n8n 2>/dev/null || true

# Auf gepatchte Version updaten (Beispiel)
npm install -g n8n@1.123.17
# bzw. n8n@2.5.2 oder neuer

Übersichten & Priorisierung

Die wichtigste operative Frage: Welche n8n-Instanzen patchen wir zuerst?

Weitere n8n-Artikel

Für eine systematische Absicherung: unsere Checkliste für sichere n8n Deployments. Für die unauthenticated RCE CVE-2026-21858: n8n Sicherheitslücke CVE-2026-21858 (Ni8mare).

Häufige Fragen aus der Praxis

Verwandte Artikel & weiterführende Ressourcen

• n8n CVE-2026-21858 (Ni8mare) – Unauthenticated RCE, technische Analyse
• Supply-Chain-Risiken bei n8n Community Nodes
• Checkliste für sichere n8n Deployments
• Blog-Archiv