n8n self-hosted absichern: Security-Update, Update-Prozess und Härtung

Am 14. Oktober 2026 hat n8n ein Security-Update veröffentlicht, das 15 Advisories auf einen Schlag schließt: fünf mit hoher und zehn mit mittlerer Schwere. Wer n8n in der Cloud nutzt, muss dafür nichts tun. Wer n8n selbst betreibt, muss handeln, und zwar nicht erst im nächsten Wartungsfenster. Für das n8n Hosting im Mittelstand ist das ein guter Anlass, den gesamten Betrieb sauber aufzustellen, statt nur eine Versionsnummer zu erhöhen.

Dieser Beitrag ordnet ein, was die Advisories bedeuten, wer für welche Patches zuständig ist, wie ein belastbarer Update-Prozess aussieht und welche Härtungsmaßnahmen sich im Betrieb bewähren. Er zielt bewusst auf Betrieb und Sicherheit. Wenn Sie zuerst klären möchten, ob n8n, Make, Zapier oder eine eigene Anwendung zu Ihnen passt, finden Sie den Vergleich in unserem Beitrag zur Workflow Automatisierung 2026.

Was die Advisories vom 14. Oktober für Ihr Hosting bedeuten

Das Update behebt 15 Sicherheitslücken, die n8n als Advisories veröffentlicht hat. Die Korrekturen stecken in drei Versionen: 1.123.85, 2.43.5 und 2.44.1. Welche davon für Sie die richtige ist, hängt davon ab, auf welcher Release-Linie Ihre Instanz heute läuft. Wer auf der 1er-Linie ist, geht auf 1.123.85, wer auf der 2er-Linie ist, auf 2.43.5 oder 2.44.1.

Drei Themen, die Sie kennen sollten

Aus den fünf Advisories mit hoher Schwere lassen sich für den Betrieb drei Muster ableiten, die über n8n hinaus typisch für Automatisierungsplattformen sind.

1. Stored XSS über Webhook-AntwortenWenn ein Workflow Inhalte aus einer Anfrage ungefiltert in eine Antwort übernimmt, kann ein Angreifer Skriptcode ablegen, der später im Browser eines Mitarbeiters ausgeführt wird. Gefährlich ist das vor allem dort, wo Mitarbeiter mit angemeldeter Sitzung im Editor arbeiten, denn dann hängt am Browser ein privilegierter Zugang zu allen Workflows und Verbindungen.
2. Credential-Secrets in FehlerdatenFehlerdaten wandern in Ausführungsprotokolle, in Error-Workflows und häufig in Benachrichtigungen per Chat oder E-Mail. Wenn dort Zugangsdaten auftauchen können, reicht ein ungünstig konfigurierter Benachrichtigungskanal, um Secrets zu streuen. Prüfen Sie nach dem Update, wohin Fehlerdaten bei Ihnen überall fließen.
3. Data Tables anderer ProjekteIn Instanzen, in denen mehrere Teams oder Abteilungen in getrennten Projekten arbeiten, ist die Trennung genau das Versprechen der Rechteverwaltung. Eine Lücke an dieser Stelle trifft deshalb vor allem Betreiber, die n8n als gemeinsame Plattform für mehrere Bereiche nutzen.

Wie dringend ist das wirklich?

Nicht jedes Advisory lässt sich in jeder Konfiguration ausnutzen, und die genauen Voraussetzungen stehen in den jeweiligen Advisories im GitHub-Repository von n8n. Als Faustregel gilt: Je offener Ihre Instanz im Netz steht und je mehr Personen mit unterschiedlichen Rechten darauf arbeiten, desto schneller sollten Sie patchen. Eine Instanz, deren Editor ohne Zugangsbeschränkung aus dem Internet erreichbar ist, gehört noch in dieser Woche auf den neuen Stand.

Hinzu kommt der Rhythmus. Es gab bereits am 1. Oktober ein Security-Update, am 14. Oktober das große mit den 15 Advisories und um den 21. Oktober eine Aktualisierung des Node.js-Images. Drei Wellen in drei Wochen zeigen, dass ein gelegentliches Update nach Gefühl nicht mehr genügt. Sie brauchen einen festen Prozess.

Cloud oder Self-Hosting: Wer patcht was?

Bei der n8n Cloud übernimmt der Hersteller das Einspielen der Korrekturen automatisch. Beim Self-Hosting liegt die gesamte Kette bei Ihnen, vom Betriebssystem über Docker bis zur n8n-Version. Die folgende Übersicht zeigt, wo die Verantwortung liegt.

Die letzte Zeile ist oft der Grund für das Self-Hosting. Wer personenbezogene Daten verarbeitet und den Serverstandort in Deutschland selbst festlegen möchte, kommt an einem eigenen Betrieb schwer vorbei. Die vorletzte Zeile wird dagegen gern vergessen: Auch in der Cloud sind Sie für die Qualität Ihrer Workflows verantwortlich, etwa für das, was ein Webhook zurückgibt.

Wann die Cloud die ehrlichere Wahl ist

Self-Hosting ist kein Selbstzweck. Wenn niemand im Unternehmen Zeit hat, Updates zu verfolgen und einzuspielen, und keine Datenschutzgründe gegen die Cloud sprechen, ist sie die sicherere Variante. Ein veraltetes, selbst betriebenes System ist riskanter als ein gut gepflegtes gehostetes. Die richtige Frage lautet daher nicht, was günstiger ist, sondern wer an einem Dienstagabend um 19 Uhr den Patch einspielt, wenn ein Advisory erscheint.

Update-Prozess und Versionsstrategie

Ein Update-Prozess muss nicht aufwendig sein, aber er muss existieren und jemandem gehören. Drei Bausteine genügen für den Anfang: festgeschriebene Versionen, ein Staging-System und ein Rollback-Plan.

Versionen festschreiben

Der häufigste Fehler im Betrieb ist das Image-Tag latest. Es klingt bequem, führt aber dazu, dass ein Neustart des Containers ungeplant eine neue Version einspielt, mit allen Risiken für laufende Workflows. Legen Sie stattdessen eine konkrete Version fest und erhöhen Sie diese bewusst. Ein schlankes Grundgerüst mit PostgreSQL sieht so aus:

services:
  postgres:
    image: postgres:16
    restart: unless-stopped
    environment:
      POSTGRES_USER: n8n
      POSTGRES_PASSWORD: ${POSTGRES_PASSWORD}
      POSTGRES_DB: n8n
    volumes:
      - postgres_data:/var/lib/postgresql/data
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U n8n"]
      interval: 10s
      retries: 5

  n8n:
    image: docker.n8n.io/n8nio/n8n:2.44.1
    restart: unless-stopped
    ports:
      - "127.0.0.1:5678:5678"
    env_file: .env
    depends_on:
      postgres:
        condition: service_healthy
    volumes:
      - n8n_data:/home/node/.n8n

volumes:
  postgres_data:
  n8n_data:

Der Port ist bewusst nur an 127.0.0.1 gebunden. Von außen erreicht man n8n ausschließlich über den Reverse Proxy, dazu mehr im Abschnitt zur Härtung.

Ein Ablauf, der in einer Stunde machbar ist

Für jedes Update hat sich dieselbe Reihenfolge bewährt:

Wichtig ist, dass jemand die Advisories aktiv verfolgt. Abonnieren Sie die Security-Hinweise im GitHub-Repository von n8n und leiten Sie sie an ein Postfach weiter, das tatsächlich gelesen wird.

Welche Release-Linie ist die richtige?

Die aktuellen Fixes erscheinen für die 1er- und die 2er-Linie. Kurzfristig dürfen Sie also bei Ihrer Linie bleiben. Mittelfristig sollten Sie den Wechsel auf die 2er-Linie einplanen, statt dauerhaft auf der älteren zu verharren, weil jede zusätzliche Linie, die Sie selbst pflegen, Ihren Update-Aufwand erhöht. Planen Sie den Wechsel als eigenes kleines Projekt mit Staging-Test, nicht als Nebenbei-Update an einem Freitagnachmittag.

Ein Hinweis zum Node.js-Image: Wenn Sie auf Basis des offiziellen Images eigene Images bauen, etwa um zusätzliche Pakete einzubinden, müssen Sie nach Aktualisierungen der Basis neu bauen. Ein reines Ziehen des neuen n8n-Images reicht in diesem Fall nicht aus.

Härtung: Zugriff, Webhooks, Secrets, Backups

Ein aktueller Stand schützt vor bekannten Lücken. Die Härtung sorgt dafür, dass unbekannte Lücken weniger Schaden anrichten können.

Zugriff auf den Editor begrenzen

Der Editor ist die Schaltzentrale und gehört nicht ins offene Internet. Setzen Sie einen Reverse Proxy mit TLS davor und beschränken Sie den Zugriff auf feste IP-Adressen oder ein VPN. Öffentlich erreichbar sein müssen nur die Pfade, über die Webhooks, Formulare und wartende Workflows von außen angesprochen werden. Ein Beispiel für nginx:

limit_req_zone $binary_remote_addr zone=n8n_hooks:10m rate=10r/s;

server {
    listen 443 ssl http2;
    server_name n8n.example.de;

    add_header X-Content-Type-Options nosniff always;
    add_header Referrer-Policy no-referrer always;

    # Produktive Webhooks, Formulare und Wartepunkte: öffentlich, mit Rate Limit
    location ~ ^/(webhook|webhook-waiting|form)/ {
        limit_req zone=n8n_hooks burst=20 nodelay;
        proxy_pass http://127.0.0.1:5678;
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-For $remote_addr;
        proxy_set_header X-Forwarded-Proto $scheme;
    }

    # Editor, API und Test-Webhooks: nur aus dem Büro-Netz oder per VPN
    location / {
        allow 203.0.113.10;
        deny all;
        proxy_pass http://127.0.0.1:5678;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-For $remote_addr;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

Aktivieren Sie außerdem für alle Benutzerkonten die Zwei-Faktor-Authentifizierung und vergeben Sie Rollen sparsam. Wer nur Workflows ausführen soll, braucht keine Administratorrechte.

Webhooks wie öffentliche Schnittstellen behandeln

Jeder Webhook ist eine Tür nach außen. Schützen Sie ihn mit einer Authentifizierung, etwa einem geheimen Header, und prüfen Sie eingehende Daten, bevor ein Workflow sie verarbeitet. Das Muster hinter dem Stored-XSS-Advisory lässt sich auch ohne Patch entschärfen: Geben Sie in Antworten niemals ungeprüfte Eingaben zurück, setzen Sie einen passenden Content-Type und liefern Sie nur das aus, was der Aufrufer wirklich braucht. Begrenzen Sie außerdem die Aufrufrate am Proxy, wie im Beispiel oben.

Secrets und Credentials sauber halten

Setzen Sie den Verschlüsselungsschlüssel von n8n explizit und sichern Sie ihn getrennt von den Datenbank-Backups. Ohne diesen Schlüssel sind gespeicherte Zugangsdaten nach einer Wiederherstellung unbrauchbar. Hinterlegen Sie keine Secrets im Klartext in Workflows, vergeben Sie API-Tokens mit minimalen Rechten und tauschen Sie Zugangsdaten nach einem Verdachtsfall aus. Für die Fehlerdaten-Problematik gilt: Error-Workflows sollten nur die nötigen Felder weitergeben, nicht das komplette Fehlerobjekt. Eine typische Grundkonfiguration in der .env-Datei:

N8N_HOST=n8n.example.de
N8N_PROTOCOL=https
WEBHOOK_URL=https://n8n.example.de/
N8N_ENCRYPTION_KEY=<langer, zufälliger Wert, separat gesichert>
N8N_SECURE_COOKIE=true
N8N_PROXY_HOPS=1
N8N_BLOCK_ENV_ACCESS_IN_NODE=true
N8N_DIAGNOSTICS_ENABLED=false
EXECUTIONS_DATA_PRUNE=true
EXECUTIONS_DATA_MAX_AGE=168

Das automatische Löschen alter Ausführungsdaten reduziert nebenbei die Menge an Daten, die im Ernstfall abfließen könnte. Prüfen Sie die genauen Variablennamen und Standardwerte immer gegen die Dokumentation Ihrer Version, denn sie ändern sich zwischen den Releases.

Backups, die sich wiederherstellen lassen

Ein Backup ist erst dann eines, wenn Sie die Wiederherstellung einmal getestet haben. Sichern Sie die Datenbank täglich, bewahren Sie mehrere Generationen auf und legen Sie eine Kopie außerhalb des Servers ab. Ein einfaches Skript genügt als Anfang:

#!/usr/bin/env bash
set -euo pipefail

STAMP=$(date +%F-%H%M)
docker compose exec -T postgres pg_dump -U n8n -Fc n8n > /backup/n8n-$STAMP.dump
find /backup -name 'n8n-*.dump' -mtime +14 -delete

Testen Sie mindestens quartalsweise, ob sich aus dem Dump auf einem frischen System eine funktionierende Instanz herstellen lässt, inklusive des gesicherten Verschlüsselungsschlüssels.

Wann eine eigene Laravel-Lösung sinnvoller ist

n8n ist ein gutes Werkzeug, aber nicht für jeden Prozess die beste Antwort. Eine eigene Anwendung, etwa auf Basis von Laravel, lohnt sich vor allem in vier Situationen.

1. Geschäftskritisch und fachlich stabilWenn Aufträge, Abrechnungen oder Kundendaten über den Workflow laufen, wollen Sie Tests, Versionsverwaltung, Code-Reviews und ein klares Rechtekonzept. Das lässt sich in Code besser abbilden als in einem visuellen Editor.
2. Viele Verzweigungen und AusnahmenJe komplexer die Logik, desto unübersichtlicher werden grafische Workflows, und desto schwerer lassen sie sich warten.
3. Einsatz in einem Produkt für Ihre Kundenn8n steht unter einer eigenen Lizenz mit Einschränkungen für die Weitergabe als Dienst. Prüfen Sie die Lizenzbedingungen sorgfältig, bevor Sie n8n in ein Angebot einbauen, das Dritte nutzen.
4. Hoher Anspruch an die SicherheitsflächeEine selbst entwickelte Anwendung hat nur die Funktionen, die Sie brauchen, und damit eine kleinere Angriffsfläche als eine Plattform mit hunderten Integrationen.

Häufig ist die beste Lösung ein Mischbetrieb: n8n für schnelle, interne und leicht ersetzbare Abläufe, eine eigene Laravel-Anwendung für den Kern, der dauerhaft stabil sein muss. Wie sich diese Entscheidung strukturiert treffen lässt, beschreiben wir im Beitrag zur Workflow Automatisierung. Für größere Vorhaben finden Sie unser Angebot unter individuelle Softwareentwicklung.

Hosting und Betrieb als Dienstleistung

Viele Unternehmen setzen n8n erfolgreich ein, haben aber niemanden, der sich um Server, Updates und Backups kümmert. Genau diese Lücke schließen wir. Wir setzen n8n auf einem Server in Deutschland auf, richten Reverse Proxy, TLS und Zugriffsschutz ein, definieren den Update-Prozess mit Staging-Test und übernehmen Backups, Monitoring und das Einspielen von Sicherheitsupdates. Bestehende Instanzen prüfen wir auf die Punkte aus diesem Beitrag und beheben die Schwachstellen.

Ob als einmalige Absicherung oder als laufende Wartung und Support: Sie behalten die Kontrolle über Ihre Daten, und Sie müssen nicht selbst jeden Advisory verfolgen. Mehr zu unserem Angebot rund um Automatisierung finden Sie auf der Seite zur Prozessautomatisierung. Wenn Sie wissen möchten, in welchem Zustand Ihre Instanz ist, sprechen Sie uns an. Ein kurzer Check zeigt in der Regel schnell, ob Handlungsbedarf besteht.

Instanz prüfen lassen

Hendrik und das Team prüfen Ihre n8n-Instanz auf die Punkte aus diesem Beitrag und übernehmen auf Wunsch Updates, Backups und Monitoring, mit Server in Deutschland.

Instanz prüfen lassen