Dezember 2025. Ein Sicherheitsforscher bei Cyera findet einen Bug im Webhook-Handler von n8n. Kein kleiner Bug. Ein CVSS 10.0 — die Maximalbewertung. Der Name: Ni8mare. Unauthenticated Remote Code Execution. Das heißt: Kein Login nötig, kein Account, keine Berechtigung. Ein einzelner HTTP-Request reicht, um die komplette Instanz zu übernehmen.
Das war der Anfang. Nicht das Ende.
Zwischen November 2025 und März 2026 wurden 7 kritische Schwachstellen in n8n veröffentlicht. Davon zwei mit CVSS 10.0 und zwei mit CVSS 9.9. Das ist beispiellos für eine Automatisierungsplattform. n8n ist quasi über Nacht vom Entwickler-Liebling zum Angriffsziel Nr. 1 unter Workflow-Tools geworden.
Und das Ganze ist nicht nur Theorie. CVE-2025-68613 (Expression Injection, CVSS 9.9) wird seit Januar 2026 aktiv in der Wildnis ausgenutzt. Das Zerobot-Botnet, eine Mirai-Variante, scannt das Internet gezielt nach verwundbaren n8n-Instanzen. Findet es eine, wird sie Teil des Botnets. Die US-Behörde CISA hat die Schwachstelle am 11. März 2026 in den Known Exploited Vulnerabilities Katalog aufgenommen. Deadline für den Patch: 25. März 2026.
Wie viele n8n-Instanzen hängen direkt am Internet? Cybersecurity News und Horizon3.ai haben im März 2026 Shodan-Scans ausgewertet. Das Ergebnis: 71.537 Instanzen sind öffentlich erreichbar. Davon laufen die meisten auf dem Standard-Port 5678, viele ohne Authentifizierung.
Noch schlimmer: Etwa 105.753 Instanzen sind anfällig für CVE-2026-21858 (Ni8mare). Das bedeutet: Über hunderttausend Maschinen, bei denen ein einziger HTTP-Request zur vollständigen Übernahme reicht. Im Februar 2026 waren laut The Hacker News und CISA noch 24.700+ ungepatchte Instanzen online.
Die Wahrscheinlichkeit, dass eure Instanz gescannt wird, ist nicht hypothetisch. Sie ist eine Frage von Stunden nach dem Deployment.
Hier wird es richtig unangenehm. n8n ist keine isolierte App. Es ist eine Integrationsplattform. Das heißt, in einer typischen Installation findet ein Angreifer:
Alle gespeicherten Credentials. Jeder API-Key, jedes OAuth-Token, jeder Datenbankzugang, den ihr in n8n hinterlegt habt. CRM-Zugang, E-Mail-Provider, ERP-Schnittstelle, Payment-Gateway. Alles liegt verschlüsselt in der Datenbank, aber der Verschlüsselungsschlüssel (N8N_ENCRYPTION_KEY) ist auf derselben Maschine. Wer Root hat, hat den Key. Wer den Key hat, hat alles.
Zugriff auf Kundendaten. Eure Workflows verarbeiten Bestellungen, Kontaktdaten, Rechnungen, E-Mails. All das fließt durch n8n. Execution-Daten werden standardmäßig gespeichert. Ein Angreifer kann vergangene Workflow-Ausführungen auslesen und bekommt damit einen Datenschatz, der weit über die n8n-Instanz hinausgeht.
Laterale Bewegung ins interne Netz. n8n läuft typischerweise in einem Docker-Container, der Zugriff auf interne Netzwerke hat. PostgreSQL, Redis, andere interne Dienste. Von dort aus kann sich ein Angreifer weiter vorarbeiten. Aus einem kompromittierten Workflow-Tool wird ein Brückenkopf ins Firmennetz.
Und dann ist da noch die rechtliche Seite. Wenn ein Angreifer über eure n8n-Instanz auf personenbezogene Daten zugreift, habt ihr 72 Stunden Zeit, das der Aufsichtsbehörde zu melden (Art. 33 DSGVO). Bei einem RCE-Exploit mit Zugriff auf Credentials und Kundendaten ist das keine theoretische Frage. Das ist ein meldepflichtiger Datenschutzvorfall.
Die gute Nachricht: Die meisten dieser Sicherheitsprobleme sind vermeidbar. Reverse Proxy, TLS, starke Authentifizierung, regelmäßige Updates. Kein Hexenwerk. Aber es muss gemacht werden. Und zwar jetzt.
Wer n8n self-hosted betreibt, übernimmt die volle Verantwortung. Kein Cloud-Anbieter patcht für euch. Keine automatischen Security-Updates. Ihr seid der Admin, der Sicherheitsbeauftragte und der Incident-Responder in einer Person.
Die nächsten Kapitel zeigen euch Schritt für Schritt, wie ihr eure Instanz absichert. Fangen wir mit dem Überblick über die konkreten Schwachstellen an.
Zwischen November 2025 und März 2026 hat n8n eine Schwachstellen-Dichte erlebt, die es so bei keinem anderen Workflow-Tool gab. Sieben CVEs, davon sechs mit CVSS 9.4 oder höher. Hier ist der Überblick, bevor wir die gefährlichsten im Detail anschauen.
| CVE | Name | CVSS | Typ | Auth nötig? | Fix-Version |
|---|---|---|---|---|---|
| CVE-2026-21858 | Ni8mare | 10.0 | Unauthenticated RCE | Nein | 1.121.0 |
| CVE-2026-21877 | File Upload RCE | 10.0 | Unrestricted File Upload | Ja | 1.121.3 |
| CVE-2025-68613 | Expression Injection | 9.9 | Authenticated RCE | Ja | 1.120.4 / 1.121.1 / 1.122.0 |
| CVE-2025-68668 | N8scape | 9.9 | Sandbox Escape | Ja | 2.0.0 |
| CVE-2026-25049 | Sanitization Bypass | 9.4 | Bypass von CVE-2025-68613-Fix | Ja | Feb. 2026 Patch |
| CVE-2026-25115 | Python Sandbox Escape | 9.4 | Sandbox Escape | Ja | Feb. 2026 Patch |
| CVE-2026-25631 | Credential Domain | 5.3 | Improper Validation | Ja | — |
Zwei Schwachstellen stechen heraus: Ni8mare und Expression Injection. Beide verdienen einen genaueren Blick.
CVSS 10.0. Unauthenticated. Remote Code Execution. Das ist die schlimmstmögliche Kombination.
Wie funktioniert der Angriff? n8n hat einen Webhook-Handler, der Formulardaten entgegennimmt. Normalerweise erwartet er Multipart-Form-Data (also Datei-Uploads). Der Bug: Der Handler prüft den Content-Type nicht richtig. Schickt ein Angreifer stattdessen JSON mit einem manipulierten files-Objekt, ruft n8n parseBody() statt parseFormData() auf.
Das klingt harmlos. Ist es nicht.
Über das manipulierte files-Objekt kann der Angreifer beliebige lokale Dateien lesen. Damit kommt er an den N8N_ENCRYPTION_KEY und die Session-Cookies. Mit dem Encryption Key entschlüsselt er alle gespeicherten Credentials. Mit den Session-Cookies fälscht er eine Admin-Sitzung. Und von dort ist es ein kurzer Weg zur Code-Ausführung auf dem Server.
Voraussetzung: Es muss mindestens ein Workflow mit einer öffentlich zugänglichen Form-Component existieren. In der Praxis ist das bei vielen Instanzen der Fall, weil n8n-Forms ein populäres Feature sind.
Betroffene Versionen: Alles vor 1.121.0. Der Fix kam am 18. November 2025 von Cyera Research Labs.
CVSS 9.9. Und anders als Ni8mare nicht nur Theorie, sondern aktiv in der Wildnis unterwegs.
n8n evaluiert Expressions in Workflows, z.B. {{ $json.name }}. Diese Expressions laufen in einer Sandbox. Sollten sie zumindest. CVE-2025-68613 zeigt: Die Sandbox-Isolation ist unzureichend. Ein Benutzer mit Workflow-Bearbeitungsrechten kann speziell konstruierte Expressions erstellen, die aus der Sandbox ausbrechen und Befehle auf Betriebssystem-Ebene ausführen. Mit den Rechten des n8n-Prozesses.
Ja, man braucht einen Account. Aber: Wenn Open Registration aktiv ist (was bei vielen Instanzen der Default ist), kann sich jeder einen Account erstellen. Und das Zerobot-Botnet macht genau das. Seit Januar 2026 scannt es das Internet nach n8n-Instanzen, registriert sich, erstellt einen bösartigen Workflow und übernimmt den Server.
Die CISA hat reagiert: Aufnahme in den KEV-Katalog am 11. März 2026. Patch-Deadline: 25. März 2026. Betroffen sind Versionen 0.211.0 bis 1.122.0.
Zwei weitere CVEs drehen sich um dasselbe Grundproblem: n8ns Sandbox ist löchrig.
CVE-2025-68668 (N8scape, CVSS 9.9): Authentifizierte Benutzer können aus der JavaScript-Sandbox ausbrechen und beliebige Kommandos auf dem Host ausführen. Der Fix dafür ist die neue Task-Runner-Architektur in n8n v2.0, die Code-Ausführung in separate Container isoliert.
CVE-2026-25115 (Python Sandbox Escape, CVSS 9.4): Selbst mit aktivierten Task Runnern konnten Angreifer aus der Python-Sandbox ausbrechen. Das zeigt, dass die Task-Runner-Isolation allein nicht reicht. Ihr müsst die erlaubten Module explizit einschränken.
CVE-2026-25049 (CVSS 9.4) ist besonders ärgerlich. Es ist ein Bypass der Schutzmaßnahmen, die für CVE-2025-68613 implementiert wurden. Die erste Sanitisierung war unzureichend. n8n hat nachgebessert, aber das zeigt: Einmal patchen und vergessen funktioniert nicht. Ihr müsst am Ball bleiben.
Im Januar 2026 deckten Sicherheitsforscher von Endor Labs einen Supply-Chain-Angriff auf das n8n-Ökosystem auf. 8 bösartige npm-Pakete tarnten sich als Community Nodes, z.B. als Google-Ads-Integration.
Was die Pakete machten: OAuth-Tokens stehlen. Im Hintergrund. Ohne dass ihr es merkt.
Das Problem dahinter: Community Nodes laufen mit denselben Rechten wie n8n selbst. Sie haben Zugriff auf das Dateisystem, auf Umgebungsvariablen und auf alle entschlüsselten API-Keys. Wenn ihr ein bösartiges Paket installiert, hat der Angreifer alles.
Die Lehre: Installiert Community Nodes nur, wenn ihr sie wirklich braucht. Prüft jedes Paket manuell. Und wenn ihr sie gar nicht nutzt: N8N_COMMUNITY_PACKAGES_ENABLED=false. Dann ist der Angriffsvektor komplett geschlossen.
Wenn eure n8n-Instanz auf einer Version vor 1.122.0 läuft, seid ihr für mindestens drei dieser CVEs verwundbar. Wenn ihr noch auf einer Version vor 2.0 seid, fehlt euch die Task-Runner-Isolation. Und wenn ihr Community Nodes ohne Audit installiert habt, wisst ihr nicht, was auf eurem Server läuft.
Die Shodan-Scans zeigen es deutlich: Tausende n8n-Instanzen hängen direkt auf Port 5678 im Internet. Ohne Reverse Proxy, ohne TLS, ohne irgendwas dazwischen. Das ist, als würde man die Haustür offenlassen und sich wundern, dass jemand reinkommt.
Die gute Nachricht: Netzwerk-Absicherung ist kein Raketenwissen. Wenn ihr Docker und ein paar Basics kennt, kriegt ihr das an einem Nachmittag hin.
n8n ist eine interne Anwendung. Sie wurde dafür gebaut, Workflows zu automatisieren, nicht um als öffentlicher Webservice zu fungieren. Der eingebaute HTTP-Server hat keine Web Application Firewall, kein Rate Limiting und keine Security-Header. Und wie die CVE-Liste zeigt: Der Webhook-Handler ist der primäre Angriffsvektor.
CVE-2026-21858 (Ni8mare) funktioniert über einen manipulierten Request an einen Webhook-Endpoint. Wer n8n direkt ins Internet stellt, gibt Angreifern einen ungefilterten Kanal zu genau dieser Angriffsfläche.
Die Lösung: Einen Reverse Proxy davorsetzen.
Zwei Optionen, die sich in der Praxis bewährt haben:
Nginx ist der Klassiker. Stabil, gut dokumentiert, riesige Community. Wenn ihr bereits Erfahrung mit Nginx habt, nehmt Nginx. Die Konfiguration ist straightforward: Proxy-Pass auf den n8n-Container, TLS-Terminierung, Security-Header, fertig.
Traefik ist die Docker-native Alternative. Es erkennt Container automatisch über Labels und holt sich TLS-Zertifikate selbständig von Let's Encrypt. Weniger Konfiguration, dafür etwas mehr Abstraktion. Ideal, wenn euer ganzer Stack auf Docker Compose läuft.
Egal welchen ihr nehmt: n8n lauscht intern auf Port 5678. Der Reverse Proxy lauscht auf 80 und 443. Und nur der Reverse Proxy ist von außen erreichbar.
Wichtig: Konfiguriert den Proxy so, dass er WebSocket-Verbindungen durchreicht. n8n braucht WebSockets für den Editor. Ohne bekommt ihr Verbindungsabbrüche im UI.
Kein TLS bedeutet: Login-Daten, API-Responses und Webhook-Payloads fließen im Klartext übers Netz. Das ist 2026 nicht mehr akzeptabel.
Let's Encrypt liefert kostenlose Zertifikate mit automatischer Erneuerung. Bei Nginx nutzt ihr Certbot. Bei Traefik ist Let's Encrypt eingebaut, ihr müsst nur den ACME-Resolver konfigurieren.
In n8n selbst setzt ihr die Environment Variable N8N_PROTOCOL=https und WEBHOOK_URL=https://eure-domain.de. Damit weiß n8n, dass es hinter TLS läuft und generiert korrekte Webhook-URLs.
HTTP-Requests auf Port 80 sollten automatisch auf HTTPS (443) redirecten. Kein Nutzer und kein Webhook-Aufruf sollte jemals unverschlüsselt kommunizieren.
Euer Reverse Proxy sollte folgende Header setzen:
Strict-Transport-Security (HSTS): Zwingt Browser, nur HTTPS zu verwenden. Setzt max-age auf mindestens ein Jahr (31536000 Sekunden). Damit verhindert ihr Downgrade-Angriffe.
X-Frame-Options: DENY: Verhindert, dass eure n8n-Instanz in einem iFrame eingebettet wird. Schützt vor Clickjacking.
X-Content-Type-Options: nosniff: Verhindert MIME-Type-Sniffing. Besonders relevant bei n8n, weil CVE-2026-21858 genau auf Content-Type-Confusion basiert.
Content-Security-Policy: Schränkt ein, welche Ressourcen der Browser laden darf. Setzt mindestens default-src 'self' als Baseline.
Diese Header kosten euch fünf Zeilen in der Nginx-Config und schließen ganze Angriffsklassen aus.
Euer Server sollte genau zwei Ports nach außen offen haben: 80 (HTTP, für den Redirect) und 443 (HTTPS). Dazu SSH für die Administration, idealerweise auf einem Non-Standard-Port.
Alles andere ist intern. Port 5678 (n8n) ist nur über den Reverse Proxy erreichbar. Port 5432 (PostgreSQL) und Port 6379 (Redis) sind nur über das interne Docker-Netzwerk erreichbar.
Mit ufw (Uncomplicated Firewall) auf Ubuntu:
ufw default deny incoming
ufw allow 22/tcp # SSH (oder euren Custom-Port)
ufw allow 80/tcp # HTTP Redirect
ufw allow 443/tcp # HTTPS
ufw enableDas wars. Vier Befehle. Damit ist euer Server schon deutlich besser abgesichert als 90 Prozent der n8n-Instanzen da draußen.
In einer typischen n8n-Installation braucht ihr drei Container: n8n, PostgreSQL und Redis. Diese kommunizieren untereinander. Aber sie müssen nicht von außen erreichbar sein.
Erstellt in Docker Compose ein internes Netzwerk. Verbindet alle drei Container damit. PostgreSQL und Redis bekommen keine Port-Mappings nach außen. Nur n8n kommuniziert mit dem Reverse Proxy.
Das Prinzip: Jeder Container kann nur das erreichen, was er zum Funktionieren braucht. PostgreSQL redet nur mit n8n. Redis redet nur mit n8n. Und n8n redet nur mit dem Reverse Proxy. Wenn ein Angreifer es irgendwie schafft, auf den Reverse Proxy zu kommen, steht er vor der nächsten Wand.
Webhooks sind das Tor zur Welt. Sie müssen von außen erreichbar sein, sonst funktionieren Integrationen nicht. Aber sie sind auch der Angriffsvektor Nr. 1.
Was ihr tun könnt:
Separate Webhook-URL konfigurieren. n8n unterstützt WEBHOOK_URL als eigene Domain oder Subdomain. Damit könnt ihr Webhook-Traffic auf Proxy-Ebene anders behandeln als Editor-Traffic.
Rate Limiting. Konfiguriert in Nginx ein Request-Limit für Webhook-Endpoints. 10-20 Requests pro Sekunde pro IP reicht für die meisten Integrationen. Alles darüber ist entweder eine Fehlkonfiguration oder ein Angriff.
IP-Allowlisting für bekannte Quellen. Wenn eure Webhooks nur von bestimmten Diensten aufgerufen werden (z.B. Shopify, HubSpot, Stripe), erlaubt nur deren IP-Ranges. Jeder andere Request wird vom Proxy geblockt, bevor er n8n erreicht.
Der n8n-Editor ist euer Admin-Panel. Er gehört nicht ins öffentliche Internet. Punkt.
Zwei Optionen:
VPN-Zugang. Die Admin-UI ist nur über VPN erreichbar. WireGuard ist schlank und schnell eingerichtet. Damit ist die gesamte Angriffsfläche auf Webhook-Endpoints reduziert.
IP-Allowlisting. Wenn VPN zu aufwändig ist: Erlaubt den Zugriff auf die Admin-UI nur von bestimmten IP-Adressen. Eurem Büro-Netzwerk, eurer festen IP. Alle anderen sehen eine 403-Seite.
Beide Ansätze verhindern, dass Angreifer überhaupt den Login-Screen sehen. Kein Login-Screen bedeutet kein Brute-Force, kein Credential Stuffing und keine Ausnutzung von Authentifizierungs-Schwachstellen.
Reverse Proxy, TLS, Firewall, interne Netzwerke, Webhook-Absicherung, Admin-UI verstecken. Das sind sechs Maßnahmen. Keine davon ist komplex. Zusammen schließen sie die häufigsten Angriffsvektoren.
Netzwerk steht, Reverse Proxy läuft, TLS ist aktiv. Jetzt geht es an die nächste Schicht: Wer darf rein, wie werden eure Secrets geschützt und wie härtet ihr den Docker-Container ab.
n8n speichert alle Credentials — API-Keys, OAuth-Tokens, Datenbankpasswörter — in der PostgreSQL-Datenbank. Verschlüsselt. Aber nur, wenn ihr den N8N_ENCRYPTION_KEY gesetzt habt.
Ohne diesen Key? Klartext. Alles.
Jeder, der Zugriff auf eure Datenbank bekommt, liest eure API-Keys wie eine Einkaufsliste. Bei einem RCE-Exploit wie Ni8mare (CVSS 10.0) ist genau das das Szenario: Der Angreifer liest den Encryption Key aus dem Dateisystem, entschlüsselt alle Credentials und hat Zugriff auf jedes System, das ihr über n8n angebunden habt.
So setzt ihr den Key richtig:
Mindestens 32 Zeichen, zufällig generiert. Kein Passwort, das ihr euch merken könnt. Kein Firmenname mit ein paar Sonderzeichen. Ein richtiger Zufallsstring:
openssl rand -hex 32Außerhalb des Containers sichern. Wenn der Container stirbt und der Key weg ist, sind alle gespeicherten Credentials verloren. Unwiderruflich. Speichert den Key in eurem Passwort-Manager, in einem externen Secrets Manager (HashiCorp Vault, AWS Secrets Manager) oder mindestens in einer .env-Datei außerhalb der Versionskontrolle.
Und dann sperrt den Zugriff auf Umgebungsvariablen:
N8N_BLOCK_ENV_ACCESS_IN_NODE=trueOhne diese Einstellung können Workflows eure Server-Umgebungsvariablen lesen. Inklusive des Encryption Keys. Das heißt: Ein einziger kompromittierter Workflow reicht, um alle Secrets eurer Instanz abzugreifen.
Multi-Faktor-Authentifizierung für alle Accounts. Keine Ausnahmen. Wenn ein Angreifer ein Passwort erbeutet (Phishing, Credential Stuffing, Leak), ist MFA die letzte Verteidigungslinie.
Für Teams ab 5 Personen lohnt sich SSO über OIDC oder SAML. Keycloak, Okta, Auth0 — egal welcher Provider, Hauptsache zentrale Benutzerverwaltung. Damit könnt ihr Mitarbeiter sofort sperren, wenn sie das Unternehmen verlassen. Ohne SSO müsst ihr jeden n8n-Account einzeln deaktivieren und hoffen, dass ihr keinen vergessen habt.
Open Registration deaktivieren. Das ist eine der am häufigsten übersehenen Einstellungen. Wenn Open Registration aktiv ist, kann sich jeder einen Account auf eurer Instanz erstellen. Über 100.000 n8n-Instanzen sind öffentlich im Internet erreichbar — viele davon mit offener Registrierung. Ein Geschenk für Angreifer.
Docker gibt euch Isolation. Aber nur, wenn ihr sie auch nutzt. Die meisten Docker-Compose-Files, die man online findet, laufen mit Standardeinstellungen. Das reicht nicht.
Kein --privileged. Nie. Ein privilegierter Container hat praktisch Root-Zugriff auf den Host. Wenn ein Angreifer über einen RCE-Exploit in den Container kommt, kommt er auch auf den Host.
Security Options setzen:
security_opt:
- no-new-privileges:true
cap_drop:
- ALLno-new-privileges verhindert, dass Prozesse im Container ihre Rechte eskalieren können. cap_drop: ALL entfernt alle Linux-Capabilities. n8n braucht keine davon.
Image-Version pinnen. Nicht :latest verwenden. Pinnt auf eine konkrete Version wie n8nio/n8n:1.121.3. Damit habt ihr zwei Vorteile: Ihr wisst genau, welche Version läuft, und ihr könnt bei Problemen sofort auf die vorherige Version zurückrollen.
Container-Images scannen. Tools wie Trivy oder Snyk prüfen eure Images auf bekannte Schwachstellen in den enthaltenen Paketen. Ein Scan pro Deployment kostet 30 Sekunden und kann euch vor einer bekannten Lücke in einer Abhängigkeit warnen.
Ab n8n v2.0 gibt es Task Runners. Die führen JavaScript- und Python-Code aus Workflows in einem separaten Prozess aus, statt direkt im n8n-Hauptprozess.
Nutzt den externen Modus. Der interne Modus ist bequemer, aber ein Sicherheitsrisiko. Im externen Modus läuft der Task Runner als eigener Container mit eingeschränkten Rechten. Selbst wenn ein Angreifer aus der Sandbox ausbricht (wie bei CVE-2025-68668, CVSS 9.9), landet er im isolierten Runner-Container statt im Haupt-n8n-Prozess.
Schränkt die erlaubten Module explizit ein über NODE_FUNCTION_ALLOW_BUILTIN und NODE_FUNCTION_ALLOW_EXTERNAL. Nur das freigeben, was eure Workflows tatsächlich brauchen.
Community Nodes sind mächtig. Sie erweitern n8n um hunderte Integrationen. Aber sie laufen mit denselben Rechten wie n8n selbst: Zugriff auf Dateisystem, Umgebungsvariablen, entschlüsselte API-Keys.
Im Januar 2026 wurden 8 bösartige npm-Pakete entdeckt, die sich als n8n-Integrationen tarnten, zum Beispiel für Google Ads. Sie stahlen OAuth-Tokens und leiteten sie an externe Server weiter.
Wenn ihr Community Nodes nicht braucht:
N8N_COMMUNITY_PACKAGES_ENABLED=falseWenn ihr sie braucht: Jedes Paket vor der Installation manuell auditieren. Prüft den Paketnamen, den Autor, die Download-Zahlen und am besten den Quellcode. Installiert nichts, was weniger als ein paar hundert wöchentliche Downloads hat. Und installiert nie ein Paket, das erst vor wenigen Tagen veröffentlicht wurde — genau so funktionierten die bösartigen Pakete im Januar.
Self-Hosting klingt erstmal nach maximaler Kontrolle. Eigener Server, eigene Daten, kein Cloud-Anbieter, der mitlesen kann. Stimmt alles. Aber es bedeutet auch: Ihr seid der Verantwortliche. Nicht n8n. Nicht euer Hosting-Provider. Ihr.
Im DSGVO-Deutsch: Ihr seid der „Verantwortliche“ nach Art. 4 Nr. 7 DSGVO. Das heißt, ihr entscheidet, welche personenbezogenen Daten verarbeitet werden und warum. Und ihr haftet, wenn etwas schiefgeht.
Bei der n8n-Cloud wäre n8n als Auftragsverarbeiter mit in der Pflicht. Beim Self-Hosting tragt ihr alles allein. Datensicherheit, Löschpflichten, Auskunftsrechte, Meldepflichten. Alles eure Baustelle.
Das ist kein Argument gegen Self-Hosting. Es ist ein Argument dafür, es richtig zu machen.
Die DSGVO verlangt in Art. 32 „geeignete technische und organisatorische Maßnahmen“. Was heißt das konkret für eure n8n-Instanz?
Verschlüsselung. TLS für alle Daten in Transit. Den N8N_ENCRYPTION_KEY für Credentials at Rest. Ohne beides habt ihr eine offene Flanke, die jeder Auditor sofort bemängelt.
Zugangskontrolle. MFA für alle Benutzer. SSO über OIDC oder SAML für zentrale Verwaltung. Rollenbasierte Zugriffe, damit nicht jeder Mitarbeiter jeden Workflow bearbeiten kann. Der Praktikant braucht keinen Zugriff auf den Workflow, der eure Kundendatenbank mit dem CRM synchronisiert.
Pseudonymisierung. Execution-Daten enthalten oft personenbezogene Daten im Klartext: E-Mail-Adressen, Namen, Bestellnummern. Alles, was durch eure Workflows fließt, landet in den Execution Logs. Pruned die regelmäßig (dazu gleich mehr).
Vertraulichkeit. Netzwerk-Isolation, Firewall, VPN für den Admin-Zugang. Alles, was in den vorherigen Kapiteln steht, ist gleichzeitig eure DSGVO-Pflicht.
Jede API, die ihr über n8n anbindet, verarbeitet möglicherweise personenbezogene Daten. CRM, E-Mail-Provider, Buchhaltungssoftware, Ticketsystem. Für jeden dieser Dienste braucht ihr einen Auftragsverarbeitungsvertrag (AVV/DPA).
Das vergessen viele. n8n ist nur die Drehscheibe. Aber über diese Drehscheibe laufen Kundennamen, E-Mail-Adressen, Bestelldaten, Mitarbeiterdaten. Jeder Workflow, der diese Daten an einen externen Service schickt, ist eine Datenverarbeitung im Sinne der DSGVO.
Erstellt eine Liste aller Services, die eure n8n-Workflows nutzen. Prüft für jeden, ob ein AVV existiert. Wenn nicht, schließt einen ab.
Art. 30 DSGVO verlangt ein Verarbeitungsverzeichnis. Für n8n heißt das: Dokumentiert, welche Workflows personenbezogene Daten verarbeiten, welche Datenkategorien betroffen sind und auf welcher Rechtsgrundlage die Verarbeitung stattfindet.
Klingt nach Bürokratie. Ist es auch. Aber im Ernstfall ist es der Unterschied zwischen „wir hatten alles dokumentiert“ und „wir haben keine Ahnung, was unsere Workflows mit den Daten machen“.
Bei automatisierter Verarbeitung in großem Umfang ist außerdem eine Datenschutz-Folgenabschätzung (DSFA) erforderlich. Wenn eure n8n-Instanz täglich tausende Kundendatensätze durch Workflows schleust, fallt ihr da rein.
Art. 33 DSGVO: Bei einer Datenschutzverletzung müsst ihr innerhalb von 72 Stunden die zuständige Aufsichtsbehörde informieren. 72 Stunden ab dem Zeitpunkt, an dem ihr die Verletzung bemerkt.
Bei den n8n-Exploits, die wir in den vorherigen Kapiteln besprochen haben, ist das keine theoretische Übung. Ni8mare (CVSS 10.0) erlaubt unauthentifizierte Remote Code Execution. Ein Angreifer kann alle gespeicherten Credentials auslesen. Wenn darunter API-Keys zu Systemen mit personenbezogenen Daten sind, habt ihr einen meldepflichtigen Breach.
72 Stunden sind nicht viel. Ihr braucht einen Incident-Response-Plan, bevor es soweit ist. Wer wird informiert (Eskalationskette)? Wer entscheidet, ob gemeldet wird? Wer schreibt die Meldung? Das sind Fragen, die ihr nicht um 3 Uhr morgens zum ersten Mal beantworten wollt.
n8n speichert standardmäßig alle Execution-Daten. Jeder Workflow-Durchlauf mit allen Input- und Output-Daten. Das können Kundennamen, Adressen, Bestellungen sein. Alles im Klartext in der Datenbank.
Aktiviert das automatische Pruning:
EXECUTIONS_DATA_PRUNE=true
EXECUTIONS_DATA_MAX_AGE=168 # 7 Tage in StundenSetzt EXECUTIONS_DATA_MAX_AGE so niedrig wie möglich. 7 Tage reichen für Debugging. Alles darüber hinaus ist ein DSGVO-Risiko, das ihr nicht braucht.
Selbst gehostet auf einem Server in der EU bedeutet: Keine Datenübertragung in Drittländer. Zumindest nicht durch eure Infrastruktur. Hetzner, IONOS, OVH — egal welcher Anbieter, Hauptsache Rechenzentrum in der EU.
Aber Vorsicht: Eure Workflows können trotzdem Daten in Drittländer schicken. Jede Cloud-API, die ihr über n8n nutzt, ob OpenAI, Google Sheets, Slack oder HubSpot, kann Daten auf Servern außerhalb der EU verarbeiten. Das ist dann ein Drittlandtransfer, der eine Rechtsgrundlage braucht (meistens Standardvertragsklauseln).
Kurz noch ein Blick auf NIS2. Seit Oktober 2024 gelten EU-weit verschärfte Anforderungen an die IT-Sicherheit für Unternehmen in kritischen Sektoren. Wenn ihr unter NIS2 fallt — Energie, Transport, Gesundheit, digitale Infrastruktur, Lebensmittel, Chemie und einige mehr — dann ist eure n8n-Instanz Teil der kritischen IT-Infrastruktur.
Das heißt: Patch-Management, Incident Response und Supply-Chain-Sicherheit (ja, die Community Nodes mit den 8 bösartigen Paketen) sind nicht nur Best Practice, sondern gesetzliche Pflicht. Mit Bußgeldern, die deutlich über die DSGVO hinausgehen können.
7 kritische CVEs in 5 Monaten. Alle mit CVSS-Scores zwischen 9.4 und 10.0. Ein aktives Botnet, das eine davon ausnutzt. CISA hat eine Deadline gesetzt.
Updates sind nicht optional. Sie sind Überlebensstrategie.
Zwischen November 2025 und März 2026 ist n8n zum meistangegriffenen Workflow-Automation-Tool geworden. Ni8mare (CVSS 10.0), Expression Injection (CVSS 9.9), N8scape Sandbox Bypass (CVSS 9.9), File Upload RCE (CVSS 10.0) — die Liste hört nicht auf.
Das Zerobot-Botnet nutzt CVE-2025-68613 seit Januar 2026 aktiv aus. Vollautomatisch. CISA hat die Schwachstelle am 11. März 2026 in den Known Exploited Vulnerabilities Katalog aufgenommen, mit Deadline 25. März. Im Februar 2026 waren noch über 24.700 ungepatchte Instanzen online.
Wer n8n betreibt und nicht regelmäßig aktualisiert, betreibt eine Zeitbombe.
Updates einfach blind einspielen ist auch keine Lösung. n8n-Updates können Breaking Changes enthalten, Workflows können sich anders verhalten, Nodes können sich ändern. Deshalb: Ein strukturierter Prozess.
Schritt 1: Backup erstellen. Bevor ihr irgendetwas anfasst. Datenbank-Dump, n8n-Datenvolume, Encryption Key. Alles. Details dazu im nächsten Abschnitt.
Schritt 2: In Staging testen. Spielt das Update auf einer Kopie eurer Instanz ein. Prüft, ob eure wichtigsten Workflows noch funktionieren. Laufen die Trigger? Kommen die richtigen Daten raus? Gibt es Fehlermeldungen in den Logs?
Schritt 3: Produktion deployen. Wenn Staging sauber läuft, geht ihr auf Produktion. Idealerweise in einem Wartungsfenster, damit niemand gerade einen kritischen Workflow ausführt.
Docker-Image-Version pinnen. Nutzt immer eine konkrete Version wie n8nio/n8n:1.121.3 statt :latest. Damit könnt ihr bei Problemen sofort zurückrollen, indem ihr einfach die alte Version wieder startet.
Ihr müsst nicht jeden Tag die CVE-Datenbank durchsuchen. Aber ihr solltet informiert werden, wenn es brennt.
CISA Known Exploited Vulnerabilities (KEV): Der Katalog listet Schwachstellen, die aktiv ausgenutzt werden. Wenn eine n8n-CVE dort auftaucht, ist Handeln sofort nötig, nicht nächste Woche.
n8n Security Advisories: Die n8n-Docs haben eine eigene Security-Seite. Abonniert die Release Notes und prüft bei jedem Update die Changelog-Einträge unter „Security“.
GitHub Watch: Setzt das n8n-Repository auf „Watch“ und filtert auf Releases. Damit bekommt ihr eine E-Mail bei jeder neuen Version.
Ein Backup, das ihr nie getestet habt, ist kein Backup. Es ist ein Hoffnungsschimmer.
Was sichern:
pg_dump pro Tag ist das Minimum./home/node/.n8n-Verzeichnis enthält Konfigurationsdateien und ggf. lokale Daten.Wie oft: Tägliches Datenbank-Backup als Minimum. Bei hohem Durchsatz öfter. Der Encryption Key ändert sich nicht, der muss nur einmal sicher abgelegt werden.
Wohin: Nicht auf demselben Server. Wenn der Server kompromittiert wird, sind die Backups gleich mit weg. Externer Storage, verschlüsselt, idealerweise in einer anderen Availability Zone oder einem anderen Rechenzentrum.
Restore testen. Mindestens einmal pro Quartal. Nehmt euer Backup, spielt es auf einer frischen Instanz ein und prüft, ob alles funktioniert. Workflows, Credentials, Benutzer. Wenn ihr den Restore erst im Ernstfall zum ersten Mal macht, werdet ihr Überraschungen erleben.
n8n bringt ein eingebautes Security-Audit-Tool mit. Es prüft eure Instanz auf häufige Konfigurationsfehler: unsichere Credentials, problematische Nodes, Datenbank-Einstellungen, Dateisystem-Berechtigungen und Instanz-Konfiguration.
Führt den Audit regelmäßig aus. Idealerweise automatisiert als Teil eurer CI/CD-Pipeline oder als Cron-Job. Die Ergebnisse geben euch einen schnellen Überblick, ob sich seit dem letzten Check etwas verschlechtert hat.
Standardmäßig loggt n8n auf die Konsole. Das reicht nicht, wenn ihr nachvollziehen müsst, was vor drei Wochen passiert ist.
N8N_LOG_OUTPUT=console,file
N8N_LOG_LEVEL=infoDamit schreibt n8n Logs sowohl auf die Konsole als auch in eine Datei. Für Sicherheits-Audits und DSGVO-Compliance braucht ihr einen persistenten Audit-Trail.
Aufbewahrung: Mindestens 12 Monate. Die letzten 3 Monate sollten sofort verfügbar sein (für schnelle Incident-Analyse), ältere Logs können in kaltem Storage liegen.
Execution-Daten prunen. Wie im DSGVO-Kapitel beschrieben: EXECUTIONS_DATA_PRUNE=true aktivieren und EXECUTIONS_DATA_MAX_AGE so niedrig wie möglich setzen. Execution-Daten sind etwas anderes als Audit-Logs. Die Logs sagen euch, wer wann was getan hat. Die Execution-Daten enthalten die tatsächlichen Workflow-Daten mit potenziell personenbezogenen Informationen.
Wenn es knallt, zählt jede Minute. Spätestens seit der 72-Stunden-Meldepflicht der DSGVO ist ein Incident-Response-Plan kein Nice-to-have mehr.
Was gehört rein: Wer wird informiert (Eskalationskette)? Wie wird die Instanz isoliert? Wie werden Credentials rotiert? Wer entscheidet, ob die Aufsichtsbehörde informiert wird? Wo liegt das Backup für den Restore?
Das alles muss dokumentiert und bekannt sein. Nicht in einem Wiki, das niemand liest. In einem Dokument, das die zuständigen Personen kennen und das regelmäßig geprüft wird.
Zum Abschluss die kompakte Übersicht. Wenn ihr diese 10 Punkte umsetzt, seid ihr besser aufgestellt als die Mehrheit der über 100.000 exponierten n8n-Instanzen:
N8N_ENCRYPTION_KEY — mindestens 32 Zeichen, zufällig, extern gesichertN8N_BLOCK_ENV_ACCESS_IN_NODE=true — Workflows dürfen keine Umgebungsvariablen lesenEXECUTIONS_DATA_PRUNE=true, MAX_AGE niedrig setzenWir prüfen eure n8n-Instanz auf die häufigsten Schwachstellen und zeigen euch, wo ihr nachbessern müsst. Konfiguration, Netzwerk, DSGVO — alles in einem Check.