n8n Security Guide: Risiken, Schwachstellen und Best Practices

Stand: 01. April 2026

n8n ist eine weit verbreitete Open-Source-Plattform für Workflow-Automatisierung – selbst gehostet oder in der Cloud. Unternehmen nutzen n8n, um APIs, Datenbanken und interne Systeme zu verbinden; dabei speichert n8n OAuth-Tokens, API-Keys und Datenbankzugänge. Weil Workflows zudem Code ausführen können, ist eine n8n-Instanz aus Sicht der IT-Sicherheit ein kritisches System: Ein erfolgreicher Angriff kann zu Credential Diebstahl, lateraler Bewegung und vollständiger Übernahme der angebundenen Infrastruktur führen. Trotzdem wird n8n Security in der Praxis oft unterschätzt – viele Teams behandeln die Plattform wie ein einfaches Low-Code-Tool statt wie Tier-0-Infrastruktur.

Dieser Guide erklärt, warum n8n ein Sicherheitsrisiko sein kann, welche typischen Risiken und bekannten Schwachstellen es gibt, und wie Unternehmen n8n durch Architektur, Zugriffskontrollen und Patch-Management sicher betreiben. Er dient als zentrale Übersicht und verlinkt auf vertiefende Artikel zu konkreten CVEs, zur Checkliste für sichere Deployments und zu Supply-Chain-Risiken bei n8n Community Nodes. Wer statt Eigenrecherche direkt eine strukturierte Prüfung der eigenen Umgebung braucht, findet hier auch unsere Services für n8n Hosting Security und n8n Flow Security.

Aktuelle Lage: Was sich bis Anfang April 2026 geändert hat

Seit der ersten Version dieses Guides hat sich die Lage weiter zugespitzt: Am 25. März 2026 hat n8n mehrere neue Advisories veröffentlicht, darunter die beiden kritischen Schwachstellen CVE-2026-33696 und CVE-2026-33660 sowie die High-Severity-Lücke CVE-2026-33663. Gepatcht sind laut Advisory die Versionen 1.123.27, 2.13.3 und 2.14.1. [Security Advisory] [Security Advisory] [Security Advisory]

Für Betreiber ist vor allem die operative Einordnung wichtig: Die beiden kritischen Lücken setzen zwar einen authentifizierten Nutzer mit Workflow-Bearbeitungsrechten voraus, genau solche Rechte sind in vielen Teams aber breiter verteilt als gedacht. Die dritte Lücke betrifft die Community Edition und ermöglicht den Diebstahl fremder generischer HTTP-Credentials. Heise wies zum Veröffentlichungszeitpunkt darauf hin, dass noch keine öffentlichen Hinweise auf aktive Ausnutzung vorlagen; das ändert aber nichts an der Dringlichkeit des Patches. [Security News]

Wichtig ist aber auch, was in vielen Zusammenfassungen der März-Welle fehlt: Am selben Tag wurden zusätzlich drei clientseitige Schwachstellen veröffentlicht, die veröffentlichte n8n-Oberflächen betreffen. Dazu gehören XSS über Binary-Data-Responses, Stored XSS im Form Trigger und XSS im Chat Trigger über Custom CSS. Damit ist 2026 nicht nur klar, dass Workflow-Editor-Rechte RCE-Risiken bergen, sondern auch, dass öffentliche Form-, Chat- und Binary-Data-Endpunkte als reale Angriffsoberfläche betrachtet werden müssen. [Security Advisory] [Security Advisory] [Security Advisory]

Hinzu kommt die Advisory-Welle vom 25. Februar 2026: Damals hat n8n unter anderem eine weitere Expression-Sandbox-Escape-RCE, eine Merge-Node-RCE, Stored XSS über verschiedene Nodes und SQL Injection in SQL-Nodes veröffentlicht. Aus Security-Sicht ist die zentrale Erkenntnis deshalb breiter als nur „eine neue CVE patchen“: n8n hat gleichzeitig Risiken auf Host-, Browser- und Datenebene. [Security Advisory] [Security Advisory] [Security Advisory] [Security Advisory]

Stand 01. April 2026 zeigt das offizielle n8n Security Overview weiterhin die Advisories vom 25. März 2026 als jüngste veröffentlichte Einträge. Parallel nennen die Release Notes inzwischen 2.13.4 als aktuelle Stable-Version und 2.14.2 als aktuelle Beta. Das ist keine neue CVE, aber ein praktischer Hinweis für den Betrieb: Wer nur auf Mindest-Fixstände schaut und danach nicht weiter aktualisiert, bleibt schnell wieder hinter dem offiziell dokumentierten Sicherheits- und Bugfix-Stand zurück. [Security Advisory] [Dokumentation]

Warum n8n ein Sicherheitsrisiko sein kann

n8n vereint mehrere Faktoren, die es aus Angreifersicht attraktiv und aus Verteidigersicht heikel machen:

• Workflow-Automatisierung mit weitreichenden Rechten: Workflows laufen im Kontext des n8n-Servers und können – je nach Konfiguration – Befehle ausführen, Dateien lesen und externe Dienste ansprechen.
• Zugriff auf viele Systeme: Eine Instanz verbindet oft Dutzende APIs, Datenbanken, Cloud-Dienste und interne Anwendungen.
• Speicherung von Credentials: OAuth-Tokens, API-Keys und Datenbankpasswörter werden zentral in n8n gehalten und von Workflows genutzt.
• Möglichkeit, Code auszuführen: Über Expressions, riskante Nodes, unsichere Integrationen oder Community-Nodes kann effektiv beliebiger Code auf dem Host ausgeführt werden.

Die möglichen Auswirkungen eines Angriffs reichen von Credential Theft über laterale Bewegung in verbundene Systeme und Datenexfiltration bis zur kompletten Übernahme von Servern und Cloud-Konten. Wer n8n produktiv einsetzt, sollte es daher von Anfang an mit denselben Sicherheitsstandards betreiben wie Identity-Provider, CI/CD-Systeme oder zentrale Datenbanken.

Typische n8n Sicherheitsrisiken

Remote Code Execution

Die gefährlichste Kategorie: Angreifer können auf dem Host, der n8n ausführt, beliebigen Code oder Systembefehle ausführen. Typische Eintrittspunkte sind:

• Workflow-Expressions: Wenn Nutzereingaben oder Workflow-Parameter ungefiltert in die Expression-Engine gelangen, kann Expression Escape oder Injection zu RCE führen.
• Execute Command Node: Erlaubt die Ausführung von Shell-Befehlen; in Kombination mit einer Account-Kompromittierung oder einer anderen Schwachstelle führt das direkt zur Host-Übernahme. Seit n8n 2.0 ist der Node aus Sicherheitsgründen standardmäßig deaktiviert.
• Unsichere Nodes: Bestimmte Integrations- oder Community-Nodes können bei fehlender Validierung Befehle oder Code ausführen; aktuelle Beispiele sind die Advisories zum Merge-Node und zu prototype-pollution-artigen Ketten.

Bekannte CVEs wie CVE-2026-25049 (Command Injection via Workflows) und CVE-2026-21858 „Ni8mare“ (unauthenticated RCE) sowie die neuen März-2026-Lücken zeigen, dass diese Risiken nicht theoretisch sind. [Dokumentation] [Dokumentation]

Öffentliche Workflow-Oberflächen

Ein wichtiges Update gegenüber vielen älteren n8n-Guides: Nicht nur Host-RCE ist relevant. Veröffentlichte Forms, Chat Trigger, Webhook-Antworten und Binary-Data-URLs können selbst zur Browser-Angriffsfläche werden. Die Advisories aus Februar und März 2026 zeigen, dass ein Nutzer mit Workflow-Bearbeitungsrechten bösartige Skripte in veröffentlichte Seiten oder Responses einschleusen kann, die anschließend im Browser anderer Nutzer ausgeführt werden.

• Form Trigger: Persistente XSS-Payloads können Formularbesucher treffen, Submission-Hijacking ermöglichen oder für Phishing genutzt werden.
• Chat Trigger: Custom CSS war in betroffenen Versionen ein Pfad für Stored XSS auf öffentlichen Chat-Seiten.
• Binary Data / Inline HTML: HTML-Antworten ohne schützende Header konnten auf dem n8n-Origin im Browser rendern und so in höher privilegierten Sessions laufen.
• Allgemeine Folge: Selbst wenn nur wenige Nutzer editieren dürfen, bleiben veröffentlichte Workflow-Oberflächen ein zusätzlicher Schutzbedarf.

Das ist besonders wichtig für Teams, die n8n als internes Low-Code-Portal, Formular-Frontend oder Chat-Interface nutzen: Browser-seitige Angriffe können Credential-Exfiltration, Workflow-Manipulation oder Privileg-Eskalation nach sich ziehen, ohne dass der Angreifer direkt Host-Zugriff braucht. [Security Advisory] [Security Advisory] [Security Advisory] [Security Advisory]

Supply-Chain-Risiken

n8n unterstützt Community Nodes – Erweiterungen aus dem npm-Ökosystem. Diese werden mit den Rechten der n8n-Instanz ausgeführt. Risiken:

• Community Nodes aus unbekannten Quellen: Können bösartigen Code enthalten oder nachträglich kompromittiert werden.
• npm-Pakete: Abhängigkeiten von Community Nodes können verwundbar oder manipuliert sein.
• Manipulierte Erweiterungen: Typosquatting, Account-Übernahme von Maintainern oder gezielte Backdoors in beliebten Nodes.

Der aktuelle Docs-Stand differenziert hier genauer als viele ältere Blogposts: n8n weist explizit darauf hin, dass Community Nodes aus npm vollen Zugriff auf die Maschine haben können. Gleichzeitig gibt es inzwischen verified community nodes, die n8n prüft und die über das Nodes-Panel installierbar sind. Das senkt das Risiko gegenüber komplett ungeprüften npm-Paketen, ersetzt aber keine eigene Freigabeentscheidung. Wenn Community Nodes nicht zwingend benötigt werden, sollten self-hosted Instanzen sie per N8N_COMMUNITY_PACKAGES_ENABLED=false vollständig deaktivieren. [Dokumentation] [Dokumentation]

Ausführlich behandeln wir das Thema im Artikel zu Supply-Chain-Risiken bei n8n Community Nodes und OAuth.

Wenn Ihre Frage weniger „Ist die Instanz sauber gehostet?“ und mehr „Welche Flows, Nodes oder Expressions sind riskant?“ lautet, passt n8n Flow Security besser.

Credential Exposure

n8n speichert Credentials zentral für die Nutzung in Workflows. Daraus entstehen Risiken:

• OAuth-Tokens: Oft mit breiten Scopes (z. B. Vollzugriff auf Google Workspace oder Microsoft 365); ein gestohlener Token ermöglicht Zugriff auf alle verbundenen Daten.
• API-Keys: Werden zentral verwaltet und sind nach einer Kompromittierung der Instanz ein attraktives Ziel.
• Generische HTTP-Credentials: In der Community Edition waren laut CVE-2026-33663 bestimmte generische HTTP-Credential-Typen ein besonders kritischer Pfad.
• Datenbankzugänge: Verbindungsstrings und Passwörter für interne oder Cloud-Datenbanken.

Sobald ein Angreifer RCE oder ausreichenden Zugriff auf die n8n-Instanz hat, kann er den Credential-Speicher auslesen und damit alle angebundenen Dienste übernehmen. Credential Management (minimale Scopes, Rotation, externe Secret-Manager) ist daher zentral. [Security Advisory]

Unsichere Deployments

Viele Installationen sind unnötig exponiert oder schwach konfiguriert:

• Öffentlich erreichbare Instanzen: n8n läuft im Internet ohne oder mit schwacher Authentifizierung.
• Fehlende oder schwache Authentifizierung: Einzelner Admin-Account ohne MFA, Standard-Credentials.
• Keine Netzwerksegmentierung: n8n steht im gleichen Netz wie produktive Systeme; bei Kompromittierung ist laterale Bewegung trivial.

Bereits durch Netzwerkabsicherung und Zugriffskontrollen lässt sich das Risiko deutlich reduzieren – ohne n8n öffentlich zu exponieren und mit striktem Least Privilege für Workflow-Berechtigungen.

Wenn Sie genau diese Hosting- und Deployment-Themen strukturiert prüfen lassen möchten, ist n8n Hosting Security der passendste Einstieg.

Bekannte n8n Schwachstellen

n8n war 2025/2026 mehrfach von kritischen Sicherheitslücken betroffen. Zwei zentrale Beispiele, die wir in eigenen Artikeln vertiefen, plus die neuen März-2026-Lücken:

Lessons Learned: Diese Schwachstellen zeigen, dass n8n wie ein kritisches System gepatcht und abgesichert werden muss. Die Advisories vom 25. März 2026 unterstreichen zusätzlich, dass nicht nur unauthentifizierte Exploits gefährlich sind: Auch zu breite Rollenmodelle und unkritisch vergebene Workflow-Bearbeitungsrechte können für eine Host-Kompromittierung reichen. Viele Instanzen liefen wochenlang ungepatcht – ein klares Zeichen dafür, dass Patch-Management und Security Awareness für Workflow-Automatisierung oft nachhinken. Unternehmen sollten Versionen überwachen und Security-Advisories von n8n sowie vertiefende Analysen (wie unsere CVE-Artikel) regelmäßig einbeziehen.

Best Practices für sichere n8n Deployments

Netzwerkabsicherung

• n8n nicht öffentlich exponieren: Die Oberfläche sollte nicht direkt aus dem Internet erreichbar sein.
• Zugriff über VPN oder Auth-Proxy: Nur autorisierte Nutzer über ein kontrolliertes Netz (VPN, Admin-VLAN) oder einen Identity-Aware Proxy (z. B. mit SSO/MFA) zulassen.
• Netzwerksegmentierung: n8n in einem eigenen Segment betreiben; Zugriff auf produktive Systeme nur über definierte Schnittstellen und mit minimalen Rechten.

Zugriffskontrollen

• Getrennte Accounts: Kein gemeinsamer Admin-Account; klare Trennung nach Rolle (z. B. Admin vs. Workflow-Editor).
• Least Privilege: Nur diejenigen Nutzer erhalten Workflow-Edit-Rechte, die sie für ihre Aufgabe brauchen; insbesondere Editor-, Member- und Projektrechte regelmäßig prüfen.
• Editor-Rechte stärker entkoppeln: Wo verfügbar, Ausführen, Bearbeiten sowie Publish/Unpublish getrennt vergeben. n8n hat die Granularität in Custom Roles weiter ausgebaut, was für sensible Workflows hilfreich ist.
• Riskante Nodes restriktiv nutzen: Execute Command, Merge im SQL-Modus, XML und ähnliche High-Impact-Nodes nur bewusst und kontrolliert einsetzen oder über NODES_EXCLUDE blockieren.
• MFA: Mehrfaktor-Authentifizierung für alle Zugriffe auf die n8n-Oberfläche erzwingen.
• Öffentliche Flows gesondert härten: Form Trigger, Chat Trigger, Webhook-Seiten und Binary-Data-Ausgaben nicht wie „harmlose Frontends“ behandeln, sondern als zusätzliche Angriffsoberfläche.

Für Business- und Enterprise-Pläne dokumentiert n8n zusätzlich instance-weite Security Settings, darunter erzwungene 2FA und Richtlinien für persönliche Spaces. Gerade in größeren Teams helfen diese Funktionen, breit verteilte Bearbeitungs- und Freigaberechte enger zu steuern. [Dokumentation] [Dokumentation]

Node- und Runtime-Hardening

• Umgebungsvariablen in Nodes blockieren: N8N_BLOCK_ENV_ACCESS_IN_NODE=true reduziert das Risiko, dass Expressions oder Code-Node-Logik an Prozess-Secrets gelangen.
• Dateizugriffe einschränken: N8N_RESTRICT_FILE_ACCESS_TO als Allowlist setzen und den Schutz für .n8n-Dateien aktiv lassen.
• Settings-Datei härten: N8N_ENFORCE_SETTINGS_FILE_PERMISSIONS=true hilft, lokale Berechtigungen für Konfigurationsdateien restriktiver zu halten.
• Git-Node konservativ betreiben: Git-Hooks deaktiviert lassen und Bare-Repos nur zulassen, wenn es technisch wirklich nötig ist.
• Unsichere oder nicht benötigte Nodes ausschließen: Für akute Mitigationen und dauerhafte Härtung NODES_EXCLUDE gezielt nutzen.

Diese Optionen ersetzen keine Patches, sind aber ein sinnvoller zusätzlicher Layer, besonders in self-hosted Umgebungen mit mehreren Editoren oder experimentellen Flows. [Dokumentation]

Credential Management

• Minimale OAuth-Scopes: Nur die nötigsten Berechtigungen bei OAuth-Integrationen anfordern.
• Secrets Management: Wo möglich externe Vaults oder Secret-Manager nutzen statt Credentials ausschließlich in n8n zu speichern.
• Regelmäßige Rotation: API-Keys und Tokens rotieren; insbesondere nach Verdacht auf Kompromittierung oder nach Mitarbeiter-Austritt.

n8n unterstützt inzwischen mehrere externe Secret-Provider. Für sensible Umgebungen ist das ein wichtiges Update, weil sich Credentials so zentraler verwalten, rotieren und projektbezogen eingrenzen lassen, statt alle Secrets dauerhaft nur in der n8n-Datenbank vorzuhalten. [Dokumentation]

Updates und Patch Management

• Security Updates schnell einspielen: Für die Advisories vom 25. März 2026 sind 1.123.27, 2.13.3 und 2.14.1 die relevanten Fix-Stände; für die Februar-Welle 1.123.22, 2.9.3 und 2.10.1.
• Versionen überwachen: Prozess etablieren, um n8n- und Abhängigkeitsversionen zu tracken und mit Advisories abzugleichen.
• Nach dem Patch validieren: Security-Audit fahren, Rechte prüfen, riskante Nodes inventarisieren und bei Community Edition auch generische HTTP-Credentials überprüfen.
• Nicht am Mindestfixstand stehen bleiben: Die Docs nennen am 01. April 2026 bereits 2.13.4 als Stable und 2.14.2 als Beta.

Zusätzlich hilfreich: n8n 2.0 hat einige Defaults sicherer gemacht, etwa die Standard-Deaktivierung von ExecuteCommand und LocalFileTrigger sowie mehr Isolation für Code-Ausführung. Diese Defaults ersetzen kein Patchen, senken aber die Grundangriffsfläche. [Dokumentation] [Dokumentation]

Ebenfalls neu relevant für den laufenden Betrieb: n8n dokumentiert einen integrierten Security Audit, der per CLI (n8n audit), API oder n8n-Node laufen kann. Der Report deckt unter anderem ungeschützte Webhooks, fehlende Security Settings, riskante Nodes, Community Nodes und veraltete Instanzen ab. Das ist kein Ersatz für ein echtes Review, aber ein guter Minimalstandard für wiederkehrende Checks. [Dokumentation]

Checkliste für sichere n8n Deployments

Eine detaillierte, praxisnahe Checkliste – mit konkreten Maßnahmen für Infrastruktur, Credential-Management, Monitoring und Incident Response – finden Sie in unserem Artikel Checkliste: Sichere n8n-Deployments für Startups, KMU & Enterprise.

Darin behandeln wir unter anderem: Infrastrukturmaßnahmen (Netzwerk, Host-Härtung, Container-Sicherheit), sicheres Credential-Management, Logging und Monitoring, Reaktion auf Vorfälle sowie Unterschiede zwischen Startups, KMU und Enterprise. Der Artikel eignet sich als zentrale Referenz für Teams, die n8n produktiv einsetzen und Sicherheit systematisch angehen wollen.

Supply-Chain-Risiken bei n8n Community Nodes

Community Nodes und das npm-Ökosystem bergen spezifische Risiken: manipulierte Pakete, Typosquatting, unsichere Abhängigkeiten und die Gefahr, dass OAuth-Tokens oder API-Keys über bösartige Nodes abfließen.

Unser vertiefender Artikel Supply-Chain-Risiken bei n8n Community Nodes und OAuth erklärt die Angriffsszenarien, gibt Empfehlungen zu Code Review und Whitelisting von Nodes und zeigt, warum viele Unternehmen Community Nodes komplett deaktivieren oder nur nach strenger Prüfung zulassen.

Wie Unternehmen n8n sicher betreiben

Die Anforderungen an n8n Security unterscheiden sich je nach Unternehmensgröße und Risikoprofil:

• Startups: Oft begrenzte Ressourcen; Fokus auf das Nötigste: n8n nicht öffentlich, starke Authentifizierung (MFA), keine oder nur geprüfte Community Nodes, zeitnahes Patchen. Die Checkliste hilft, Prioritäten zu setzen.
• KMU: Klare Zugriffskontrollen, Segmentierung, Credential-Management und Patch-Prozesse. Sobald Formulare, Chats oder öffentliche Webhooks genutzt werden, zusätzlich Browser-Angriffsflächen mitdenken.
• Enterprise: n8n wie Tier-0 behandeln: dedizierte Segmentierung, zentrales Secrets Management, getrennte Rollen für Edit/Execute/Publish, regelmäßige Audits und Incident-Readiness.

Wann ein Security Review sinnvoll ist

Ein gezielter Security Review oder IT-Security Check für n8n lohnt sich in typischen Situationen:

• Neue n8n-Installation: Von Anfang an Architektur und Hardening richtig aufsetzen.
• Viele Integrationen oder sensible Daten: Wenn OAuth-Tokens, Kundendaten oder kritische APIs angebunden sind.
• Compliance-Anforderungen: Vor oder nach Audits (z. B. ISO 27001, SOC 2, branchenspezifische Vorgaben).
• Verdacht auf Kompromittierung oder nach bekannt gewordenen CVEs: Schnelle Betroffenheitsprüfung, Rotation von Credentials und Hardening.

Für Hosting, Exponierung und Betriebsfragen ist n8n Hosting Security der direkteste Einstieg. Für Analyse und Hardening Ihrer Workflows passt n8n Flow Security.

Wie wir helfen können

Six Eight Consulting unterstützt Startups, KMU und Enterprise im DACH-Raum bei der Absicherung von n8n und anderer kritischer Infrastruktur:

• n8n Hosting Security: Betroffenheitsprüfung, Architektur- und Konfigurationsreview für Exponierung, Zugriffsschutz, Segmentierung und Patch-Stand.
• n8n Flow Security: Analyse und Hardening von Flows, Nodes, Expressions, Credentials und riskanten Mustern.
• Hardening: Konkrete Umsetzung von Netzwerkabsicherung, Zugriffskontrollen, Credential Management und Flow-Anpassungen.
• Architekturberatung: Sichere Integration von n8n in bestehende Infrastruktur und Compliance-Rahmen.
• Incident Response: Unterstützung bei Verdacht auf Kompromittierung – Credential-Rotation, Log-Analyse, Containment.

Die passenden Leistungsseiten dazu: n8n Hosting Security und n8n Flow Security.

Fazit

n8n ist ein kritisches System: Es hat Zugriff auf Credentials, APIs und interne Systeme und kann Code ausführen. Security muss von Anfang an mitgedacht werden – nicht erst nach einem Vorfall oder einer öffentlich gewordenen CVE. Mit Netzwerkabsicherung, strikten Zugriffskontrollen, sachgemäßem Credential Management und zeitnahem Patch-Management lassen sich die Risiken erheblich reduzieren.

Dieser Guide und die verlinkten Artikel zu CVE-2026-25049, CVE-2026-21858 (Ni8mare), dem März-2026-Update zu CVE-2026-33696, CVE-2026-33660 und CVE-2026-33663, der Checkliste für sichere n8n Deployments und Supply-Chain-Risiken bei Community Nodes bilden eine zentrale Anlaufstelle für n8n Security. Bei Bedarf unterstützen wir Sie mit Security Review, Hardening und Incident Response.