n8n Sicherheitsupdate September 2026: 14 Advisories, Fixversionen und Härtung

n8n selbst betreiben und auf dem aktuellen Stand halten? WZ-IT installiert und betreibt n8n in Ihrer Umgebung, inklusive Updates, Backups und Monitoring, siehe n8n Managed Hosting und CVE-Monitoring. Termin vereinbaren

Am 30. September 2026 hat n8n 14 neue Security Advisories veröffentlicht, zehn davon mit der Einstufung high und vier mit medium. Drei der Lücken sind ohne n8n-Konto erreichbar, eine weitere erlaubt Codeausführung im Git-Node, eine andere die Übernahme des Owner-Kontos über den MCP-Server. Behoben sind sie in n8n 2.41.4 (stable), 2.42.1 (beta) und 1.123.83 (1.x-Linie).

Es ist das dritte Sammelupdate innerhalb eines Monats. Dieser Beitrag ordnet die 14 Advisories nach Angriffsvoraussetzung, zeigt in einer Versionsmatrix, welche Fixversion welches Problem behebt, und beschreibt die Härtung, die eine n8n-Instanz unabhängig vom nächsten Update weniger anfällig macht. Alle Angaben haben den Stand 1. Oktober 2026 und folgen der Advisory-Übersicht von n8n bei GitHub.

Inhaltsverzeichnis

1. Was am 30. September veröffentlicht wurde
2. Welche Version die Lücken behebt
3. Die 14 Advisories im Überblick
4. Lücken ohne Anmeldung
5. Lücken für angemeldete Nutzer
6. Drei Sammelupdates im September
7. Übergangslösungen, wenn das Update warten muss
8. n8n dauerhaft härten
9. Updates planbar machen
10. Unser Vorgehen bei WZ-IT
11. Weiterführende Guides

Was am 30. September veröffentlicht wurde

Dass keine CVE-Nummern vergeben sind, hat eine praktische Folge: Schwachstellen-Scanner, die ausschließlich nach CVE-Kennungen arbeiten, erkennen diese Lücken möglicherweise nicht. Maßgeblich ist die GHSA-Kennung in der GitHub-Advisory-Datenbank von n8n. Von den 18 Advisories des Updates vom 2. September tragen 16 eine CVE-Nummer, die Einträge vom 16. und 30. September bislang keine.

Welche Version die Lücken behebt

n8n veröffentlicht in drei Linien. Die stable-Version ist für den Produktivbetrieb gedacht, beta ist die jeweils neueste Version, und für n8n 1.x erscheinen weiterhin Patchversionen (n8n Docs, Installation mit Docker).

Quelle: n8n Releases bei GitHub, Stand 1. Oktober 2026.

Zwei Sonderfälle:

• 2.42.0 reicht nicht. Diese Version vom 29. September behebt nur GHSA-p3pg-xw4f-m72c. Alle anderen Lücken der beta-Linie sind erst in 2.42.1 geschlossen.
• Für 2.40.x gibt es keinen Patch. Die letzte Version dieser Linie, 2.40.7, erschien am 25. September und ist damit älter als die Advisories. Der Weg führt auf 2.41.4.

Aus der Versionsangabe allein lässt sich bei n8n nicht ablesen, ob eine Instanz verwundbar ist. Entscheidend ist der Abgleich der installierten Version mit der Fixversion ihrer Linie.

Die 14 Advisories im Überblick

Die Spalte "Linien" zeigt, welche Release-Linien laut Advisory betroffen sind. Ein Advisory, das nur 2.x nennt, betrifft Funktionen, die es in 1.x nicht gibt, und umgekehrt.

Zusammengefasst: Auf einer 2.x-Instanz sind zwölf der 14 Advisories relevant, auf einer 1.x-Instanz sieben.

Lücken ohne Anmeldung

Diese drei Advisories sind ohne n8n-Konto erreichbar und deshalb für jede Instanz relevant, deren Webhook-, Form- oder Chat-Routen aus dem Internet erreichbar sind.

Send-and-Wait HMAC-Bypass (GHSA-728h-pmr2-7cgh). Der Endpunkt für wartende Ausführungen akzeptiert eine Send-and-Wait-Referenz in zwei Formen und wählte die Prüfung, bevor er die zweite Form normalisierte. Eine Anfrage in dieser Form wurde ohne die Signatur angenommen, die eine Freigabe eigentlich verlangt. Wer den Resume-Token einer Ausführung kennt, kann eine Freigabe erteilen, die für eine andere Person gedacht war. Die nachfolgenden Schritte laufen mit den Credentials des Workflow-Besitzers und können je nach Workflow bis zur Ausführung von Befehlen reichen. Besonders betroffen sind Workflows, in denen ein öffentlicher Trigger vor einer Freigabe steht und den Resume-Token preisgibt.

Unbegrenzte OAuth-Clients (GHSA-3qcw-p65v-c7vq). Der nicht authentifizierte Authorize-Endpunkt legte für jede abweichende Client-Kennung einen neuen Datensatz an, ohne Obergrenze, Ablauf oder Löschpfad. Ein Angreifer ohne Konto kann die Tabelle so lange wachsen lassen, bis der Datenträger voll ist. Das ist ein Verfügbarkeitsproblem, kein Datenabfluss.

Workflow-Ausführung über den Webhook-Pfad (GHSA-4c7j-qff5-r9cx). Bei Webhooks mit dynamischem Pfad ist eine vom Server erzeugte Kennung der einzige nicht erratbare Teil der URL. Die Auflösung prüfte nur den Pfad, sodass ein Aufruf ohne diese Kennung den Workflow trotzdem startete, unter den Credentials des zugehörigen Projekts. Derselbe Resolver bedient die Form- und MCP-Routen. Eine am Webhook-Node konfigurierte Authentifizierung greift weiterhin.

Lücken für angemeldete Nutzer

Die übrigen elf Advisories setzen ein n8n-Konto voraus. Das senkt das Risiko für Instanzen mit wenigen, vertrauenswürdigen Nutzern, nicht aber für Instanzen, auf denen mehrere Teams, externe Dienstleister oder Fachbereiche eigene Workflows bauen.

Bemerkenswert ist die Häufung bei den neueren KI-Funktionen: Agents, MCP-Server und AI Workflow Builder stehen zusammen in fünf der 14 Advisories. Wer diese Module nicht nutzt, kann sie deaktivieren und verkleinert damit die Angriffsfläche dauerhaft. Wie sich Rechte und Freigaben für KI-Agenten grundsätzlich gestalten lassen, beschreibt der Artikel KI-Agenten: Rechte und Freigaben.

Der MSSQL-Fall zeigt ein Muster, das im September auch den Oracle- und den Supabase-Node betraf (GHSA-4wf3-rgqr-xcp3, GHSA-xrqg-3xcp-h45x): Werte aus Ausdrücken, die direkt in eine Abfrage eingesetzt werden, sind anfällig für Injection. Das Advisory empfiehlt, den Node auf typeVersion 1.1 oder neuer zu bringen und dynamische Werte über Query Parameters zu übergeben.

Drei Sammelupdates im September

n8n bündelt Sicherheitshinweise seit dem 13. Mai 2026 in einem zweiwöchentlichen Update, jeweils mittwochs. Kritische Lücken, die nicht warten können, meldet n8n weiterhin sofort (n8n Blog zur Vulnerability Disclosure). Im September 2026 ergab das drei Termine:

Quellen: Security Update 2. September 2026, Security Update 16. September 2026 und die Advisory-Liste bei GitHub. Die Einstufung critical kam im September nicht vor, die letzten kritischen Advisories stammen vom 13. Mai 2026.

Die Zahl der Advisories sagt allein wenig über die Sicherheit der Software. n8n führt den Anstieg auf mehr Prüfungen durch Sicherheitsforscher zurück. Für den Betrieb zählt etwas anderes: Wer n8n selbst betreibt, braucht einen Prozess, der alle zwei Wochen eine neue Fixversion einspielen kann, ohne dass jedes Update zum Einzelprojekt wird. Nach dem bisherigen Rhythmus wäre der nächste Termin der 14. Oktober 2026.

Übergangslösungen, wenn das Update warten muss

Jedes Advisory nennt Workarounds und den Hinweis, dass sie das Risiko nicht vollständig beseitigen. Sie sind für die Zeit bis zum Update gedacht.

Die Beschränkung der Webhook-Routen ist nur dort umsetzbar, wo die Aufrufer bekannt sind, etwa bei internen Systemen oder festen IP-Bereichen eines SaaS-Anbieters. Öffentliche Formulare und Chats lassen sich so nicht absichern.

n8n dauerhaft härten

Die Advisories zeigen, welche Funktionen wiederholt betroffen sind: Code- und Git-Nodes, Ausdrucks-Sandbox, Credentials in geteilten Workflows, öffentliche Endpunkte und zuletzt die KI-Module. Eine Härtung, die diese Bereiche einschränkt, wirkt über das einzelne Update hinaus.

Quellen: n8n 2.0 Breaking Changes, SSRF-Schutz, Sicherheits-Umgebungsvariablen.

Die Seite zu den Sicherheits-Umgebungsvariablen führt für N8N_BLOCK_ENV_ACCESS_IN_NODE noch false als Standard, die Breaking-Changes-Liste zu n8n 2.0 dagegen true. Wer sich auf den Wert verlässt, setzt ihn deshalb explizit.

Neben den Variablen zählen drei organisatorische Punkte:

• Netzexposition trennen. Der Editor gehört in ein internes Netz oder hinter ein VPN. Öffentlich erreichbar sind nur die Routen, die ein Workflow tatsächlich braucht, also Webhooks, Formulare oder Chats. Ein Reverse Proxy wie Caddy kann die Pfade getrennt behandeln; die Grundinstallation beschreibt der Beitrag n8n auf Ubuntu mit Caddy.
• Rechte knapp halten. Viele Advisories betreffen Editoren geteilter Workflows. Wer Workflows nur mit Personen teilt, die alle darin genutzten Credentials auch selbst nutzen dürfen, verliert durch diese Lückenklasse wenig.
• MFA für alle Konten mit Owner- oder Admin-Rolle. Bei GHSA-5jr4 war MFA der Unterschied zwischen betroffen und nicht betroffen.

Updates planbar machen

n8n veröffentlicht nach eigener Aussage fast jede Woche eine neue Minor-Version und empfiehlt, mindestens einmal im Monat zu aktualisieren (n8n Docs, Update). Mit dem zweiwöchentlichen Sicherheitsrhythmus reicht ein monatliches Fenster für Sicherheitsfixes allerdings nicht immer aus. n8n selbst empfiehlt Betreibern einen dokumentierten Schnellweg für Sicherheitsupdates.

Ein Ablauf, der sich bewährt:

1. Version fest pinnen. Im Docker-Compose-File eine konkrete Version wie n8nio/n8n:2.41.4 statt latest. So ist jederzeit klar, was läuft, und ein Rollback ist eindeutig.
2. Bei der stable-Linie bleiben. n8n empfiehlt stable für den Produktivbetrieb und weist darauf hin, dass beta instabil sein kann. Der Fall 2.42.0 zeigt zudem, dass eine neue beta-Version nicht automatisch alle Fixes enthält.
3. Sicherheitshinweise abonnieren. Die zweiwöchentlichen Updates erscheinen im n8n-Forum und per E-Mail; die GHSA-Liste bei GitHub lässt sich beobachten.
4. Vor dem Update sichern. Datenbank-Backup (PostgreSQL oder SQLite) und Sicherung des Verschlüsselungsschlüssels, ohne den gespeicherte Credentials nicht mehr lesbar sind.
5. Nach dem Update testen. Kritische Workflows mit festen Testdaten auslösen, Fehler-Workflows und Ausführungsprotokoll prüfen.

Wer Schwachstellen über mehrere selbst betriebene Anwendungen hinweg verfolgen muss, findet den übergreifenden Ansatz im Beitrag CVE-Monitoring für Self-Hosted-Software. Die fehlenden CVE-Nummern bei n8n zeigen dabei, warum ein Monitoring auch Hersteller-Advisories auswerten sollte und nicht nur CVE-Feeds.

Unser Vorgehen bei WZ-IT

1. Bestandsaufnahme. Installierte Version und Release-Linie, Betriebsart (Docker, Kubernetes, Queue Mode), erreichbare Routen, Nutzer und Rollen, genutzte Module wie Agents oder MCP-Server.
2. Betroffenheit bewerten. Abgleich der Instanz mit den Advisories, inklusive der Frage, welche Lücken ohne Anmeldung erreichbar sind und welche Workflows öffentliche Trigger vor Freigabeschritten haben.
3. Update einspielen. Backup von Datenbank und Verschlüsselungsschlüssel, Update auf die Fixversion der passenden Linie, Test der wichtigsten Workflows.
4. Härten. Umgebungsvariablen, ausgeschlossene Nodes, SSRF-Schutz, MFA, Trennung von Editor und öffentlichen Routen am Reverse Proxy.
5. Laufender Betrieb. Im n8n Managed Hosting übernimmt WZ-IT Installation, Updates, Backups und Monitoring. Neue n8n-Advisories werden im Rahmen des CVE-Monitorings nach Betroffenheit und Exposition bewertet. Die Konditionen stehen im Angebot.

Für einen Überblick über alle Betriebsleistungen steht der Hub Managed Operations zur Verfügung.

Weiterführende Guides

• n8n auf Ubuntu mit Caddy installieren, Grundinstallation mit Docker und automatischen TLS-Zertifikaten.
• Geschäftsprozesse mit n8n und KI-Agenten automatisieren, Einsatzfelder von n8n im Unternehmen.
• CVE-Monitoring für Self-Hosted-Software, wie Schwachstellen über viele Anwendungen hinweg verfolgt werden.
• LiteLLM-Sicherheitslücke: Gateway absichern, eine kritische Lücke im KI-Gateway und die passende Härtung.
• KI-Agenten: Rechte und Freigaben, wie Berechtigungen und Human-in-the-loop für Agenten gestaltet werden.
• n8n Managed Hosting, Installation, Workflow-Entwicklung und Betrieb durch WZ-IT.

Sicherheitsupdate eingespielt, aber die Härtung fehlt noch? Wir prüfen Version, Konfiguration und Netzexposition Ihrer n8n-Instanz und übernehmen auf Wunsch den laufenden Betrieb. Termin vereinbaren

Quellen

• n8n, Security Advisories bei GitHub
• GHSA-728h-pmr2-7cgh, Send-and-Wait HMAC Bypass
• GHSA-3qcw-p65v-c7vq, Unbounded OAuth Client Persistence
• GHSA-4c7j-qff5-r9cx, Cross-Project Workflow Execution via Webhook Path
• GHSA-5jr4-xmvf-frmj, MCP Workflow-Validation Owner Account Takeover
• GHSA-x8wx-g24x-3549, Code Execution in the Git Node
• GHSA-5qpp-pqww-h7fp, SQL Injection in the Microsoft SQL Node
• n8n Releases bei GitHub
• n8n Community, Security Update 2. September 2026
• n8n Community, Security Update 16. September 2026
• n8n Blog, How n8n Handles Vulnerability Disclosure
• n8n Docs, Installation mit Docker (Release-Linien stable und beta)
• n8n Docs, Update n8n
• n8n Docs, v2.0 Breaking Changes
• n8n Docs, SSRF-Schutz aktivieren
• n8n Docs, Sicherheits-Umgebungsvariablen