Ein beliebtes Automatisierungs-Tool wie n8n ist schnell in produktiven Prozessen verankert – umso unangenehmer, wenn genau dort gleich mehrere gravierende Sicherheitslücken auftauchen. Was bedeuten die aktuellen Findings konkret für Admins und Teams, die n8n im Alltag einsetzen?
In n8n wurden insgesamt elf Schwachstellen bekannt, darunter drei kritische Lücken mit hoher Auswirkung. Besonders brisant: In mehreren Szenarien reichen bereits bestimmte Rechte innerhalb von n8n aus, um den Schritt vom Workflow-Baukasten zur Codeausführung auf dem Server zu machen. Eine der kritischen Schwachstellen betrifft den SQL-Query-Modus: Angemeldete Nutzer mit der Berechtigung, Workflows zu erstellen oder zu ändern, können darüber beliebigen Code auf dem n8n-Server ausführen oder Dateien ablegen (CVE-2026-27497, CVSS4 9.4). Zwei weitere kritische Punkte sind Sandbox-Ausbrüche: einmal über manipulierte Expressions in Workflow-Parametern (CVE-2026-27577, CVSS4 9.4) und einmal über den JavaScript-Task-Runner (CVE-2026-27495, CVSS4 9.4). In der Standardeinstellung kann das laut Bericht im Worst Case zur vollständigen Kompromittierung des n8n-Hosts führen.
Neben den drei kritischen Lücken wurden weitere Schwachstellen mit hohem und mittlerem Risiko adressiert. Dazu zählen unter anderem Stored-XSS über verschiedene Nodes (CVE-2026-27578, CVSS4 8.5) sowie eine Möglichkeit zur unauthentifizierten Expression-Auswertung via Form Node (CVE-2026-27493), die zwar sehr hoch bewertet wird, in der praktischen Einstufung aber „nur“ als hohes Risiko gilt. Ergänzt wird das Paket durch mehrere mittlere Risiken – etwa Umgehungen von Schutzmechanismen (Guardrail/SSO), Auth-Bypass in einem Chat-Trigger-Node sowie Webhook-Fälschungen bei GitHub- und Zendesk-Triggern. Auch SQL-Injection-Probleme in Datenbank-Nodes werden genannt.
Die gute Nachricht: Es gibt fehlerbereinigte Versionen. Als geschlossen gelten die Lücken ab n8n 2.10.1, 2.9.3 und 1.123.22 (sowie allen neueren Releases). Wer n8n in einem Docker-Setup betreibt, kann das Update typischerweise direkt über die Container-/Image-Verwaltung einspielen. Da bereits Anfang Februar ebenfalls mehrere teils kritische Lücken gefixt wurden, zeigt sich ein Muster: Patch-Management und saubere Rechtekonzepte sind hier keine „Best Practice“, sondern Pflicht.