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, das auch auf dem eigenen Server betrieben werden 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. Der Hersteller kündigte nach Erscheinen von 2.0 noch drei Monate Sicherheits- und Fehlerkorrekturen für Version 1.x an, danach nicht mehr. Diese angekündigte Übergangsfrist endete rechnerisch im Frühjahr 2026. Für eine konkrete Installation sind die aktuell unterstützten Versionen und Sicherheitsmeldungen zu prüfen.

Wer eine n8n-Installation selbst betreibt und lange nicht aktualisiert hat, darf funktionierende Workflows nicht als Beleg für laufende Sicherheitsunterstützung verstehen. Entscheidend sind die installierte Version, aktuelle Sicherheitsmeldungen und die Herstellerangaben zur Unterstützung.

Was 2.0 anders macht

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

• Code läuft über Task Runner. Diese sind ab 2.0 standardmässig aktiv. Das allein ist noch keine sichere Produktionsisolierung: Im internen Modus läuft der Runner als derselbe Betriebssystembenutzer wie n8n. Für Produktion und sensible Daten empfiehlt die aktuelle Herstellerdokumentation externe Runner mit zusätzlicher Härtung.
• 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. Stattdessen dokumentiert n8n Dateisystem, Datenbank oder S3-kompatiblen Speicher. Der passende Modus hängt von Betriebsart und Konfiguration ab; ausreichend Speicherkapazität muss vorhanden sein.

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.

Für diese beiden deaktivierten Bausteine dokumentiert n8n die Ausschlussliste NODES_EXCLUDE. Wenn ein bestehender Workflow einen davon benötigt, sind zunächst Zweck, Berechtigungen und eine sicherere Alternative zu prüfen. Eine gezielte Änderung der Liste gehört in eine getestete Migration; alle Sperren pauschal zu entfernen ist keine Standardlösung.

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? Für n8n 1.x kündigte der Hersteller eine dreimonatige Übergangsfrist nach 2.0 an; den aktuellen Status der konkreten Version nicht aus laufenden Workflows ableiten.
• 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.

Primärquellen und Prüfstand

• n8n: Einführung von 2.0 und angekündigte Unterstützung für 1.x
• n8n: Änderungen und Migrationspfade für 2.0
• n8n: interne und externe Task Runner, Grenzen und Produktionsbetrieb

Veröffentlicht im Juli 2026; Nachtrag vom 10. Oktober 2026: Primärquellen ergänzt, Aussagen zu Runner-Isolierung und Binärspeicher präzisiert. Der angekündigte Unterstützungszeitraum ist keine Prüfung der aktuellen Sicherheitslage Ihrer konkreten Installation. Vor einem Upgrade Version, Migrationsbericht, Speicherart und Wiederherstellung prüfen.