n8n-Updates und Sicherung: Wer kümmert sich darum?

Wer n8n auf einem eigenen Server betreibt, braucht eine benannte Person, die es aktualisiert und sichert (im Folgenden Betreuer), und eine Vertretung. Die Sicherheitsmeldungen des Herstellers sind zahlreich, aber von den als kritisch eingestuften setzen fast alle ein angemeldetes Konto voraus. Eine Sicherung ist erst vollständig, wenn der Verschlüsselungsschlüssel dabei ist, und erst brauchbar, wenn jemand die Wiederherstellung einmal ausprobiert hat.

n8n ist ein Werkzeug, das Programme zu automatischen Abläufen („Workflows“) verbindet. „Selbstbetrieb“ heißt: Es läuft auf einem Server, den Sie oder Ihr Dienstleister einrichten und pflegen, nicht beim Hersteller. Die Kostenseite behandelt der Beitrag Cloud oder selbst betreiben.

Wie viele Sicherheitsmeldungen es gibt

Auf der Seite „Security Advisories“ des Herstellers stehen Stand 13. November 2026 insgesamt 242 veröffentlichte Meldungen. Nach der Einstufung des Herstellers sind 22 kritisch, 104 hoch, 114 mittel und 2 niedrig. 228 davon wurden 2026 veröffentlicht. In den zehn vollen Monaten Januar bis Oktober waren es 223, also im Mittel gut 22 je Monat. Sie erschienen an nur 22 Tagen, meist gebündelt (am 10. Juni und am 2. September je 18 an einem Tag).

Die Zahl allein sagt wenig. In der Überschrift von 106 der 242 Meldungen steht ein einzelner Baustein („Node“), und 204 nennen mehrere Versionslinien, in denen der Fehler behoben wurde. Eine hohe Zahl kann auch bedeuten, dass ein Hersteller Fehler offenlegt. Ob n8n mehr oder weniger Lücken hat als andere Werkzeuge, lässt sich daraus nicht ablesen; Vergleichszahlen habe ich nicht erhoben.

Was in den kritischen Meldungen steht

Ich habe die 22 kritischen Meldungen im Einzeltext gelesen. 21 davon setzen nach dem Wortlaut ein angemeldetes Konto voraus, bei 18 ausdrücklich eines mit dem Recht, Abläufe anzulegen oder zu ändern. Ein Beispiel ist die Lücke CVE-2025-68613 (CVE ist die einheitliche Kennung einer Sicherheitslücke): Ausdrücke, die ein angemeldeter Nutzer in einen Ablauf einträgt, können Programmcode auf dem Server ausführen. Behoben ist das ab Version 1.122.0. Als vorläufige Maßnahme nennt der Hersteller, das Bearbeiten von Abläufen nur vertrauenswürdigen Nutzern zu erlauben. Die Schwere wird unterschiedlich bewertet: Der Eintrag in der NVD, der US-Schwachstellendatenbank des NIST, führt auf der Skala von 0 bis 10 zwei Werte, 9,9 (kritisch) von GitHub als Meldestelle und 8,8 (hoch) von der NVD selbst.

Eine Ausnahme gibt es: CVE-2026-21858 betrifft formularbasierte Abläufe. Ein Angreifer ohne Anmeldung kann Dateien auf dem Server lesen (Schwere 10,0 von 10). Betroffen sind die Versionen ab 1.65.0 bis vor 1.121.0, behoben ist der Fehler in 1.121.0. Eine offizielle Umgehung gibt es nicht, nur den Rat, öffentlich erreichbare Webhook- und Formularadressen bis zum Update einzuschränken. Webhook-Adressen sind die Adressen, über die andere Programme einen Ablauf von außen auslösen. Die letzte kritische Meldung stammt vom 13. Mai 2026, danach kam bis zum Abrufdatum keine weitere.

Das BSI hat zu n8n zwischen Januar und Mai 2026 mindestens fünf Warnungen des CERT-Bund veröffentlicht, die ich gelesen habe, alle als „hoch“ eingestuft. CERT-Bund ist die Meldestelle des BSI für Sicherheitswarnungen. Die Warnung vom Februar nennt mehrere Schwachstellen, über die ein Angreifer Programmcode ausführen kann. Ein Nutzer berichtet im Herstellerforum von einem BSI-Schreiben, das sein Hoster weiterleitete und das zum Aktualisieren aufforderte. Das ist ein ungeprüfter Erfahrungsbericht.

Für einen kleinen Betrieb heißt das: Es braucht einen festen Rhythmus, keine Eile bei jeder Meldung. Drei Fragen entscheiden, wie schnell Sie handeln. Ist n8n aus dem Internet erreichbar? Lässt sich die Lücke ohne Anmeldung ausnutzen? Und wer hat ein Konto mit dem Recht, Abläufe zu ändern?

Wer aktualisiert

Nach der Dokumentation erscheint in den meisten Wochen eine neue Nebenversion. Für den Produktivbetrieb gilt die Version stable, beta ist die neueste und kann instabil sein. Stand 13. November 2026 war stable 2.47.7. Die Dokumentation rät, mindestens einmal im Monat zu aktualisieren, die Hinweise zu Änderungen zu lesen und das Update zuerst auf einer Testinstanz zu probieren. Vor dem Update empfiehlt sie eine vollständige Sicherung.

Auch beim Cloud-Dienst des Herstellers wählt laut Dokumentation der Inhaber der Instanz Version und Update-Rhythmus. Die Frage bleibt also auch dort bei Ihnen.

Die folgende Regelung ist ein Vorschlag des Autors, keine Vorgabe von Hersteller oder BSI:

Wie Sie eine ausgebliebene Sicherung und andere stille Fehler bemerken, beschreibt der Beitrag Stille Fehler: woran Sie merken, dass ein Ablauf nicht läuft.

Die Sicherung und der Schlüssel

n8n legt beim ersten Start einen zufälligen Schlüssel an und speichert ihn im Ordner .n8n. Mit ihm werden Zugangsdaten verschlüsselt, bevor sie in die Datenbank kommen. Zugangsdaten sind die Passwörter und Zugriffsschlüssel, mit denen n8n sich bei Ihrem Mailkonto oder anderen Diensten anmeldet. Laut Hersteller gilt: Ohne den Schlüssel aus der Konfigurationsdatei oder einen selbst gesetzten N8N_ENCRYPTION_KEY lassen sich eine wiederhergestellte Datenbank oder ein verschlüsselter Export nicht entschlüsseln.

Der Export mit n8n export:workflow --backup und n8n export:credentials --backup ist deshalb keine vollständige Sicherung. Er enthält laut Dokumentation nur Abläufe und Zugangsdaten. Benutzer und Rollen, Ausführungsverlauf, Variablen und Einstellungen samt Schlüssel fehlen. Der Export mit --decrypted schreibt Zugangsdaten im Klartext. Der Hersteller rät, diese Datei wie die Zugangsdaten selbst zu behandeln und nach der Wiederherstellung zu löschen.

Eine vollständige Sicherung besteht nach der Dokumentation aus dem Ordner .n8n und, falls Sie PostgreSQL statt der Standarddatenbank SQLite nutzen, aus der Datenbank, gesichert mit deren eigenem Werkzeug. Der Ordner bleibt auch dann Teil der Sicherung, weil der Schlüssel dort liegt. Dazu kommen ausgelagerte Daten und selbst eingebundene Nodes, falls vorhanden.

Bei SQLite ist n8n vor dem Kopieren zu stoppen, sonst kann die Kopie unstimmig werden. In Docker liegt der Ordner im Volume n8n_data unter /home/node/.n8n. Ein Verzeichnis backups/ im Container bleibt nicht erhalten, die Dateien müssen nach außen gelegt werden. Wiederherstellen lässt sich nur mit der passenden Konfiguration, also Datenbankzugang und gegebenenfalls eigenem Schlüssel.

Die Datenschutz-Grundverordnung nennt in Artikel 32 Absatz 1 als mögliche Maßnahmen die Fähigkeit, Daten bei einem technischen Zwischenfall rasch wiederherzustellen (Buchstabe c), und ein Verfahren zur regelmäßigen Überprüfung der Maßnahmen (Buchstabe d). Ob und wie das bei Ihnen gilt, klärt Ihr Datenschutzbeauftragter.

Der Aufwand

Der Beitrag zu den Kosten rechnet für den Selbstbetrieb mit 2 Stunden im Monat: 1 Stunde Update, 0,5 Stunden Kontrolle der Sicherung, 0,5 Stunden für Störungen und Meldungen. Das sind Annahmen, keine Messwerte. Mit zwei Wiederherstellungsproben im Jahr zu je 2 Stunden sind es 12 × 2 + 2 × 2 = 28 Stunden im Jahr, gut 2 Stunden im Monat. Entscheidend ist, dass die Zeit eingeplant ist und jemandem gehört.

Vertraglich und organisatorisch regeln

Betreibt Ihr Dienstleister n8n für Sie, gehört das Folgende in den Vertrag. Die Lizenzseite klärt der Beitrag n8n-Lizenz: was erlaubt ist.

1. Wer aktualisiert, und in welcher Frist nach einer kritischen Meldung?
2. Wer sichert, wohin, wie oft, und wie weisen Sie nach, dass die Sicherung läuft?
3. Wer besitzt den Schlüssel? Eine Kopie muss bei Ihnen liegen, nicht nur beim Dienstleister.
4. Wann wird die Wiederherstellung probiert, und wer meldet das Ergebnis?
5. Wie melden Sie einander Störungen und Sicherheitsvorfälle, und was geschieht beim Ende des Vertrags?

Verarbeitet der Dienstleister dabei personenbezogene Daten für Sie, verlangt Artikel 28 der DSGVO einen Vertrag mit festgelegtem Inhalt (Absatz 3), schriftlich, auch in einem elektronischen Format (Absatz 9). Dazu gehört, dass der Dienstleister die Daten nach Abschluss nach Ihrer Wahl löscht oder zurückgibt, sofern keine Speicherpflicht besteht (Buchstabe g). Ob das bei Ihnen zutrifft, klärt Ihr Datenschutzbeauftragter oder Anwalt.

Im eigenen Betrieb genügt eine halbe Seite: Name der Person und der Vertretung, die Tabelle von oben, der Ort der Schlüsselkopie. Die Vertretung hat die Wiederherstellung einmal selbst durchgeführt.

Was Sie jetzt tun können

1. Sehen Sie in Ihrem n8n nach, welche Version läuft, und vergleichen Sie sie mit stable in der Dokumentation.
2. Prüfen Sie, ob der Schlüssel getrennt vom Server gesichert ist und ob Ihre Geschäftsführung ihn findet.
3. Benennen Sie eine verantwortliche Person und eine Vertretung und übernehmen Sie die Tabelle.
4. Spielen Sie die Sicherung einmal auf einem Testrechner ein und notieren Sie, wie lange das dauert.