n8n-Sicherheitsupdates im Griff behalten

Wer n8n selbst hostet, betreibt Software mit Zugriff auf Credentials, Datenbanken und interne Systeme. Im September 2026 hat n8n mehrere Sicherheits-Advisories veröffentlicht. Für kleine Teams ohne eigenes Betriebsteam stellt sich damit eine praktische Frage: Wie bekommst du Updates zuverlässig eingespielt, ohne dass produktive Workflows ausfallen? Ich beschreibe hier den Ablauf, den ich in Projekten nutze.

Was hat n8n im September 2026 veröffentlicht?

Am 2. September 2026 erschien eine Gruppe von Advisories. Darunter ein Advisory zu einem Expression Sandbox Escape über manipulierte Shared Built-ins in Verbindung mit Code-Printer-Injection, das laut n8n zu Codeausführung führen konnte. Als behoben nennt n8n dort die Versionen 1.123.76, 2.37.7 und 2.38.2. Ein zweites Advisory beschreibt Prototype Pollution im Workflow-Structure-Summary mit möglicher Dienstblockade, behoben in 2.37.7 und 2.38.2.

Am 16. September 2026 folgte eine weitere Gruppe. Die offizielle Übersicht führt dort unter anderem Probleme bei Webhook-Signaturprüfung, Credential-Schutz, Supabase-Filtern, MongoDB-Chat-Memory, der Installation von Community Packages und projektbezogenen Variablen auf. Mehrere davon sind als High eingestuft, etwa die Umgehung des Credential-Tamper-Guards, die Supabase-Filter-Injection und die Offenlegung von Chat-Historien über den MongoDB-Chat-Memory-Node.

Am 18. September 2026 kamen Releases der 2.39er- und 2.40er-Reihe. 2.39.8 enthält eine Korrektur zur Reparatur von Data-Encryption-Keys, die als unverarbeitete Instance Keys gespeichert waren. 2.40.3 enthält ebenfalls eine entsprechende Korrektur. Das ist relevant, weil der Instance Key die Verschlüsselung deiner Credentials betrifft.

Welche Version brauche ich konkret?

Das hängt von deinem Release-Zweig ab. n8n pflegt mehrere Linien parallel. Ein Advisory nennt deshalb oft mehrere behobene Versionen. Die folgende Übersicht fasst zusammen, was in den offiziellen Quellen zum September 2026 dokumentiert ist.

Praktisch heißt das: Schau nach, in welchem Zweig du bist, und suche in der Advisory-Übersicht die passende behobene Version. Releases und Advisories sind getrennte Bereiche. Die Releases zeigen, was verfügbar ist. Die Advisories zeigen, welche Funktion betroffen war, wie schwer das eingestuft wurde und ab welcher Version es behoben ist. Für eine Update-Entscheidung brauchst du beides.

Wie aktualisiere ich, ohne Workflows oder Credentials zu verlieren?

Der Ablauf ist immer der gleiche. Er dauert bei einer kleinen Instanz nicht lange, sobald er einmal dokumentiert ist.

1. Version feststellen und notieren. Die installierte Version gegen die offiziellen Releases und Advisories prüfen.
2. Backup erstellen. Datenbank, n8n-Konfiguration und insbesondere den Instance Key sichern, der für die Verschlüsselung relevant ist.
3. Backup testweise wiederherstellen. Ein Backup, das du nie zurückgespielt hast, ist nur eine Annahme.
4. In einer Testumgebung aktualisieren. Nutze eine Kopie oder einen Export der produktiven Konfiguration.
5. Kernfunktionen prüfen. Wichtige Workflows, Credentials, Webhooks und Queue-Worker durchgehen.
6. Produktiv aktualisieren im festen Wartungsfenster. Mit dokumentiertem Rückfallweg auf die vorherige Version.
7. Nach dem Update gezielt testen. Besonders die Bereiche, die in den September-Advisories auftauchen.

Nur das Docker-Image zu aktualisieren, reicht nicht als Prüfung. Die Korrektur in 2.39.8 zu Data-Encryption-Keys zeigt, warum: Wenn der Instance Key nicht sauber vorliegt, betrifft das deine gespeicherten Credentials und damit den Zugriff auf alle angebundenen Systeme. Sichere ihn getrennt und dokumentiere, wo er liegt.

Welche Workflows teste ich nach dem Update zuerst?

Ich priorisiere nach den Bereichen, die in den September-Advisories ausdrücklich genannt sind. Das spart Zeit gegenüber einem kompletten Durchlauf aller Workflows.

• Webhooks, vor allem solche mit Signaturprüfung durch externe Dienste
• Credentials, insbesondere bei geteilten Projekten und mehreren Nutzern
• Community Nodes und alles, was über die Community-Package-Installation kam
• Datenbank-Nodes, in den Advisories vom 16. September etwa Supabase und MongoDB-Chat-Memory
• Code- und Expression-Funktionen, betroffen vom Sandbox-Advisory vom 2. September
• Source Control und OAuth, ebenfalls Gegenstand von Advisories vom 2. September

Wie organisiere ich das dauerhaft im kleinen Team?

Ein eigenes DevOps-Team brauchst du dafür nicht. Du brauchst eine verantwortliche Person, einen dokumentierten Ablauf und eine Rückfallmöglichkeit. Konkret hat sich bei mir Folgendes bewährt.

• Feste Zuständigkeit. Eine Person prüft Advisories und Releases, eine zweite kennt den Ablauf als Vertretung.
• Benachrichtigung einrichten. Das n8n-Repository auf GitHub beobachten, damit neue Advisories und Releases im Posteingang landen.
• Wartungsfenster im Kalender. Ein wiederkehrender Termin pro Monat, plus ein außerplanmäßiger Slot bei Advisories mit hoher Einstufung.
• Exposition reduzieren. n8n nicht unnötig direkt aus dem Internet erreichbar machen, individuelle Konten statt geteilter Zugänge, administrative Rechte nur für den nötigen Personenkreis. Das sind allgemeine Schutzmaßnahmen, keine Garantie gegen eine bestimmte Schwachstelle.
• Änderungen protokollieren. Datum, alte Version, neue Version, aufgetretene Probleme. Zwei Zeilen reichen.

Ein Update ist nie risikofrei. Releases enthalten neben Sicherheitskorrekturen auch Verhaltensänderungen. Genau deshalb sind Backup und Rückfallplan der Kern des Ablaufs, nicht das Update selbst. Wenn dich eine Schwachstelle betrifft, die Zugriff auf Credentials oder personenbezogene Daten ermöglichen könnte, kläre die rechtliche Bewertung mit deiner Datenschutz- oder Rechtsberatung. Das ist keine Einschätzung, die ich dir abnehmen kann.

Was ist der realistische Aufwand?

Für eine kleine Instanz mit überschaubarer Workflow-Zahl ist das eine planbare Routine: Advisories und Releases prüfen, Backup ziehen, Testumgebung aktualisieren, produktiv nachziehen, Kernworkflows durchklicken. Aufwendig wird es nur beim ersten Mal, wenn du Backup und Testumgebung erst aufbaust. Danach ist es Fleißarbeit. Wer diesen Schritt überspringt, bemerkt Probleme erst, wenn ein Workflow im Kundenkontakt ausfällt.

Wenn du unsicher bist, ob dein n8n-Setup und dein Update-Prozess tragen, schau mit mir gemeinsam drauf. Du kannst dafür ein KI-Audit buchen. Wir gehen deine Instanz, deine kritischen Workflows und deinen Wartungsablauf durch und du weißt danach, wo der nächste sinnvolle Schritt liegt.