Wenn die eigene Automatisierung keine Sicherheitsupdates mehr bekommt

Automatisierung hat eine unangenehme Eigenschaft. Wenn sie funktioniert, schaut niemand mehr hin. Das macht sie so wertvoll, und es wird zum Problem, sobald die Software darunter altert.

Ein aktuelles Beispiel betrifft alle, die n8n selbst betreiben. n8n ist eines der verbreitetsten Werkzeuge, um Systeme miteinander zu verbinden, und das einzige der grossen drei, das man auf dem eigenen Server laufen lassen kann. Wer das tut, ist für die Aktualisierung selbst verantwortlich. Und die stand zuletzt an.

Was passiert ist

n8n hat am 15. Dezember 2025 die Version 2.0 veröffentlicht, nach einer Beta ab dem 8. Dezember. Der Hersteller beschreibt das Release ausdrücklich nicht als Feature-Sprung, sondern als Arbeit an Sicherheit, Verlässlichkeit und Geschwindigkeit.

Der Punkt, auf den es ankommt, steht im Kleingedruckten. Version 1.x wurde nach dem Erscheinen von 2.0 noch drei Monate lang mit Sicherheits- und Fehlerkorrekturen versorgt, danach nicht mehr. Diese Frist ist im Frühjahr 2026 abgelaufen.

Wer also eine n8n-Installation auf einem eigenen Server betreibt und seit einem Jahr nicht hingeschaut hat, betreibt seit einigen Monaten Software, für die keine Sicherheitslücken mehr geschlossen werden. Nicht, weil etwas kaputt wäre. Die Workflows laufen weiter, das ist ja das Tückische.

Was 2.0 anders macht

Die wichtigsten Änderungen betreffen Dinge, die vorher grosszügig geregelt waren:

• Code wird isoliert ausgeführt. Sogenannte Task Runners sind jetzt standardmässig aktiv. Eigener Code in einem Workflow läuft in einer abgeschotteten Umgebung statt direkt im Hauptprozess.
• Umgebungsvariablen sind gesperrt. Code-Bausteine konnten bisher ungehindert auf die Umgebungsvariablen des Servers zugreifen. Dort liegen typischerweise Zugangsdaten. Dieser Zugriff ist jetzt zu.
• Zwei gefährliche Bausteine sind abgeschaltet. „Execute Command" (führt beliebige Systembefehle aus) und „Local File Trigger" (greift auf das Dateisystem zu) sind standardmässig deaktiviert.
• Der In-Memory-Modus für Binärdaten ist entfernt. Wer grosse Dateien durch Workflows schickt, muss den dateibasierten Modus verwenden.

Dazu kommt spürbar mehr Tempo. Ein neuer Datenbanktreiber für SQLite ist laut Hersteller in eigenen Messungen bis zu zehnmal schneller.

Warum der Umstieg trotzdem weh tun kann

Alle vier Änderungen sind richtig. Alle vier können eine laufende Automatisierung stilllegen.

Wenn ein Workflow bisher ein Passwort aus einer Umgebungsvariable gelesen hat, findet er es nach dem Upgrade nicht mehr. Wenn irgendwo ein Systembefehl ausgeführt wurde, etwa um ein Backup anzustossen, ein Skript zu starten oder eine Datei zu verschieben, ist dieser Baustein nach dem Upgrade schlicht nicht mehr da.

Und hier wartet eine Falle, die im Dezember 2025 gleich mehrere Leute erwischt hat: Die naheliegende Umgebungsvariable zum Wiedereinschalten (N8N_NODES_INCLUDE) tut nicht, was man erwartet. Ein Fehlerbericht dazu wurde vom Projekt mit dem Vermerk „funktioniert wie vorgesehen" geschlossen. Der Weg führt stattdessen über NODES_EXCLUDE, also über die Ausschlussliste, aus der der Baustein wieder herausgenommen werden muss.

Für den Zugriff auf Umgebungsvariablen gibt es entsprechend N8N_BLOCK_ENV_ACCESS_IN_NODE. Damit lässt sich das alte Verhalten wiederherstellen. Nur sollte man das als Notlösung behandeln und nicht als Ziel. Wenn ein Workflow Zugangsdaten aus Umgebungsvariablen zieht, gehören sie eigentlich in die Zugangsdatenverwaltung von n8n.

n8n liefert für die Vorbereitung ein Migrationswerkzeug mit, das eine bestehende Installation vor dem Upgrade auf Probleme prüft. Wer umsteigt, sollte damit anfangen und nicht mit dem Upgrade selbst.

Ein brauchbarer Ablauf sieht deshalb anders aus als „einspielen und schauen, was passiert". Zuerst eine Kopie der Installation, dann das Prüfwerkzeug darauf loslassen, dann die beanstandeten Workflows einzeln durchgehen: umbauen oder das alte Verhalten vorübergehend zurückholen. Erst danach das Produktivsystem. Der zeitraubende Teil ist nie das Upgrade selbst, sondern diese Liste. Wer sie überspringt, findet sie trotzdem, nur eben im laufenden Betrieb und in beliebiger Reihenfolge.

Der Punkt, der über n8n hinausgeht

Dieser Fall ist kein n8n-Problem. Er trifft jeden Betrieb, der Software selbst betreibt. Zwischen „läuft" und „ist gepflegt" liegt eine Lücke, die man nicht sieht.

Bei einem Onlineshop fällt es auf, wenn er nicht erreichbar ist. Bei einer Automatisierung im Hintergrund fällt gar nichts auf. Sie arbeitet weiter, während die Grundlage darunter veraltet. Bemerkt wird es erst, wenn eine Schnittstelle sich ändert oder jemand eine Lücke ausnutzt.

Die Frage ist deshalb nicht, ob man auf 2.0 umsteigt. Die Frage ist, wer bei Ihnen überhaupt weiss, dass diese Entscheidung ansteht.

Dagegen hilft etwas Unspektakuläres: eine Liste. Welche Software läuft im Betrieb, in welcher Version, von wem, und wie lange bekommt genau diese Version noch Sicherheitsupdates. Eine Seite reicht. Sie ist an dem Tag vollständig, an dem man sie schreibt, und veraltet danach langsam wieder. Ihr Wert liegt trotzdem nicht in der Pflege, sondern darin, dass die Frage überhaupt einmal gestellt wurde. Ohne sie bemerkt man das Ende einer Unterstützungsfrist erst, wenn es Monate zurückliegt.

Was das für einen kleinen Betrieb heisst

Wenn Sie Automatisierungen einsetzen, die auf einem eigenen Server laufen, sind drei Fragen fällig:

• Welche Version läuft bei uns? Erschreckend oft weiss das niemand. Das lässt sich in fünf Minuten klären.
• Bekommt sie noch Sicherheitsupdates? Bei n8n 1.x lautet die Antwort seit dem Frühjahr Nein.
• Wer bemerkt es, wenn das nächste Mal etwas ansteht? Das ist die eigentliche Frage, und sie hat nichts mit n8n zu tun.

Wer seine Automatisierung nicht selbst hostet, sondern einen Cloud-Dienst nutzt, ist von dieser konkreten Sache nicht betroffen. Dort aktualisiert der Anbieter. Das ist der ehrliche Vorteil der gemieteten Lösung, und der Preis dafür, dass die Daten das eigene Haus verlassen. Warum es auch bei dieser Frage keine allgemeingültig richtige Antwort gibt, steht in diesem Artikel.

Für uns gehört das Nachziehen solcher Aktualisierungen zur laufenden Betreuung: Ein System, das gebaut wurde, bleibt beobachtet und wird angepasst, wenn sich etwas darunter ändert. Wenn Sie nicht wissen, wie es bei Ihnen um diesen Punkt steht, ist das ein guter Anlass für eine Bestandsaufnahme.

Stand: Juli 2026. Versionsangaben und Umgebungsvariablen entsprechen der Dokumentation von n8n zum Zeitpunkt der Veröffentlichung.