Es gibt eine Klasse von Software, die in den vergangenen zwei Jahren fast unbemerkt zum Nervensystem vieler mittelständischer Unternehmen geworden ist: Workflow-Automatisierung. Werkzeuge wie n8n, mit denen sich ohne tiefe Programmierkenntnisse E-Mails, Datenbanken, KI-Modelle, Webshops und ERP-Systeme zu durchgängigen Abläufen verketten lassen, sitzen heute an erstaunlich sensiblen Stellen. Sie haben Zugriff auf API-Schlüssel, Datenbank-Passwörter, Postfächer und – immer häufiger – auf die Sprachmodelle, die als „Agenten" eigenständig Entscheidungen treffen.

Am 27. Januar 2026 wurde mit CVE-2026-1470 eine Schwachstelle in n8n öffentlich, die mit einem CVSS-Score von 9.9 an der oberen Grenze der Kritikalität liegt. Sie erlaubt authentifizierten Angreifern, beliebigen Code auf dem Server auszuführen, der die Workflows betreibt. Was das in der Praxis bedeutet, lässt sich am besten an einem realistischen Szenario erzählen.

Das Einstiegsszenario

Stellen Sie sich einen Montagmorgen in einem mittelständischen Maschinenbauunternehmen vor. Ein Mitarbeiter der internen IT öffnet die Monitoring-Oberfläche und stellt fest, dass über das Wochenende ungewöhnlich viele Workflow-Ausführungen stattgefunden haben – mitten in der Nacht, zu Zeiten, in denen normalerweise nichts läuft. Die Automatisierungsplattform, die seit anderthalb Jahren still und zuverlässig Angebote vorbereitet, Rechnungen prüft und Support-Anfragen vorsortiert, hat plötzlich ein Eigenleben entwickelt.

Was hier nach einem harmlosen Konfigurationsfehler aussieht, ist in Wahrheit das Symptom eines viel grundsätzlicheren Problems: Eine Software, die als bequemes Bindeglied gedacht war, ist zur mächtigsten und am schlechtesten überwachten Komponente der gesamten IT-Landschaft geworden. Und genau diese Komponente hatte eine Lücke, durch die ein Angreifer aus einer simplen Workflow-Berechtigung vollständige Kontrolle über den Server gewinnen konnte.

Die technische Analyse: Wenn die Sandbox keine Wände hat

Um zu verstehen, warum CVE-2026-1470 so gefährlich ist, muss man wissen, wie n8n intern arbeitet. Workflows bestehen aus einzelnen Knoten, die Daten verarbeiten. Damit Anwender flexibel auf diese Daten zugreifen können, bietet n8n sogenannte Expressions – kleine Code-Ausdrücke, mit denen sich Werte aus vorhergehenden Schritten berechnen, umformen oder kombinieren lassen. Diese Ausdrücke werden zur Laufzeit ausgewertet.

Genau hier liegt das Problem. Die Schwachstelle ist als CWE-95 klassifiziert – „Improper Neutralization of Directives in Dynamically Evaluated Code", umgangssprachlich Eval Injection. Die Expression-Auswertung von n8n war nicht ausreichend vom darunterliegenden Node.js-Laufzeitumfeld isoliert. Die gedachte Sandbox, die den Ausdruck nur in einem eng begrenzten Kontext ausführen sollte, ließ sich umgehen. Ein Angreifer, der einen Workflow anlegen oder bearbeiten darf, konnte aus diesem Kontext ausbrechen und beliebigen JavaScript-Code mit den vollen Rechten des n8n-Serverprozesses ausführen.

Der Kern des Problems ist also keine exotische Speicherverletzung, sondern ein konzeptioneller Fehler: Eine Funktion, die für Komfort gedacht war – das flexible Auswerten von Ausdrücken –, wurde zum Werkzeug der vollständigen Übernahme. Erschwerend kam mit CVE-2026-0863 eine zweite, hochkritische Sandbox-Escape-Schwachstelle hinzu, die im selben Zeitraum bekannt wurde. Beide gemeinsam machten deutlich, dass die Isolationsschicht von n8n strukturell zu schwach war.

Wichtig für die richtige Einordnung: Die Ausnutzung setzt Authentifizierung voraus. Es handelt sich also nicht um eine Lücke, die jeder anonyme Besucher aus dem Internet auslösen kann. Aber – und das ist die Pointe – in vielen Unternehmen haben mehrere Personen die Berechtigung, Workflows zu erstellen oder zu bearbeiten. Werkstudenten, externe Dienstleister, Fachabteilungen, die ihre eigenen Automatisierungen bauen. Und ein erheblicher Teil der n8n-Installationen ist direkt aus dem Internet erreichbar, oft schlecht abgesichert, weil sie als „internes Tool" wahrgenommen werden. Aus einem kompromittierten Mitarbeiterkonto, einem schwachen Passwort oder einem erfolgreichen Phishing-Angriff wird so der direkte Weg zur Codeausführung auf einem Server, der die Schlüssel zum halben Unternehmen verwahrt.

Behoben ist die Schwachstelle in den Versionen 1.123.17, 2.4.5 und 2.5.1. Wer eine ältere Version betreibt, muss handeln – und zwar mit dem Bewusstsein, dass ein verwundbarer n8n-Server kein isoliertes Werkzeug ist, sondern ein Knotenpunkt mit weitreichenden Zugriffsrechten.

Die Geschichte der Bergischen Verfahrenstechnik Külper GmbH

Die Bergische Verfahrenstechnik Külper GmbH – ein fiktives, aber typisches Unternehmen – ist ein Hersteller von Dosier- und Mischanlagen mit rund 180 Mitarbeitern, ansässig zwischen Wuppertal und Remscheid. Klassischer Mittelstand: solide Ingenieurskunst, gesunde Auftragsbücher, eine schlanke IT-Abteilung mit drei Personen, die alles am Laufen halten.

Vor knapp zwei Jahren hatte Tobias Külper, der für die Digitalisierung zuständige Geschäftsführer der zweiten Generation, eine kleine Revolution angestoßen. Statt teure Beratung für ein monolithisches Automatisierungsprojekt zu beauftragen, hatte sein damals neuer IT-Leiter Sven Albrecht n8n eingeführt – als pragmatisches Werkzeug, um die vielen kleinen, lästigen Routineaufgaben zu erschlagen. Und es funktionierte. Eingehende Angebotsanfragen wurden automatisch klassifiziert und mit Eckdaten an den Vertrieb weitergeleitet. Lieferantenrechnungen wurden per OCR ausgelesen, gegen Bestellungen abgeglichen und vorkontiert. Seit einem halben Jahr lief sogar ein KI-gestützter Workflow, der eingehende Support-Mails las, den technischen Sachverhalt zusammenfasste und einen Antwortentwurf vorbereitete.

Was niemand so richtig auf dem Schirm hatte: Dieser eine n8n-Server hatte im Laufe der Zeit Zugangsdaten zu erstaunlich vielen Systemen angesammelt. Den API-Schlüssel des Sprachmodell-Anbieters. Die Zugangsdaten zum Mailserver. Ein Datenbank-Passwort für das ERP-Auslesemodul. Den Token für das Ticketsystem. Den Webhook in den firmeninternen Chat. Jeder einzelne Zugang war für sich genommen harmlos eingerichtet worden, „nur für diesen einen Workflow". In der Summe war daraus ein Generalschlüssel geworden.

Als die Meldung zu CVE-2026-1470 die Runde machte, las Sven Albrecht sie zunächst mit dem distanzierten Interesse, mit dem man Sicherheitsmeldungen über fremde Produkte überfliegt. Erst beim zweiten Lesen traf ihn die Erkenntnis: Das betraf seine Installation. Die n8n-Version, die bei Külper lief, war elf Monate alt. Und der Server war, weil eine externe Marketingagentur einen Webhook brauchte, über eine Subdomain direkt aus dem Internet erreichbar.

Albrecht tat in den folgenden Stunden vieles richtig. Er nahm den Server umgehend vom Netz, isolierte ihn und begann mit der Spurensuche. Was er fand, war beunruhigend, aber kein Worst Case: In den Ausführungsprotokollen entdeckte er tatsächlich verdächtige nächtliche Workflow-Läufe, die nicht von einem Menschen ausgelöst worden sein konnten. Jemand hatte die Lücke genutzt, um den Server systematisch nach gespeicherten Zugangsdaten zu durchsuchen. Die Frage war nicht mehr, ob Anmeldedaten abgeflossen waren, sondern welche.

Es folgte eine unangenehme Woche. Jeder einzelne Token, jedes Passwort, jeder API-Schlüssel, den der n8n-Server jemals gesehen hatte, musste als kompromittiert betrachtet und rotiert werden – beim Sprachmodell-Anbieter, beim Mailserver, im ERP, im Ticketsystem. Külper hatte Glück im Unglück: Der ERP-Zugang war ein reiner Lesezugang, und der Angreifer hatte offenbar primär nach verwertbaren Cloud-Schlüsseln gesucht, nicht nach Konstruktionsdaten. Ein finanzieller Schaden im großen Stil blieb aus. Aber der Schreck saß tief, und die Aufarbeitung kostete Albrechts Team eine Woche, die sie nicht hatten.

Im Nachgang, bei der gemeinsamen Aufarbeitung mit einem externen Sicherheitspartner, formulierte Tobias Külper den Satz, der zum Leitmotiv des folgenden halben Jahres wurde: „Wir haben einem Werkzeug, das wir als Hilfskraft eingestellt haben, die Schlüssel zum ganzen Haus gegeben – ohne es je zu fragen, ob es damit umgehen kann."

Die breitere Einordnung: Automatisierung ist die neue Schatten-IT

Die Geschichte der Külper GmbH ist deshalb so lehrreich, weil sie ein Muster sichtbar macht, das sich quer durch den Mittelstand zieht. Low-Code- und No-Code-Automatisierung hat enorme Produktivitätsgewinne gebracht – und genau deshalb eine gefährliche Eigendynamik entwickelt. Diese Werkzeuge werden eingeführt, weil sie schnell Ergebnisse liefern, ohne dass die IT-Sicherheit von Anfang an mit am Tisch sitzt. Sie wachsen organisch. Niemand entscheidet bewusst, dass eine Plattform die Schlüssel zu sieben Systemen verwahren soll – es passiert einfach, Workflow für Workflow.

Mit dem Aufkommen agentischer KI verschärft sich diese Dynamik dramatisch. Ein klassischer Automatisierungs-Workflow folgt festen Regeln: Wenn A, dann B. Ein agentischer Workflow hingegen gibt einem Sprachmodell die Freiheit, selbst zu entscheiden, welche Werkzeuge es in welcher Reihenfolge benutzt. Genau das macht KI-Agenten so mächtig – und genau das vergrößert die Angriffsfläche. Wer einem Agenten die Berechtigung gibt, E-Mails zu versenden, Datenbanken abzufragen und Code auszuführen, hat ein System geschaffen, dessen Verhalten nicht mehr vollständig vorhersehbar ist. Kombiniert man das mit einer Codeausführungs-Lücke wie CVE-2026-1470, potenzieren sich die Risiken.

Es geht dabei nicht darum, Automatisierung oder KI zu verteufeln. Im Gegenteil: Unternehmen, die diese Technologien nicht einsetzen, werden im Wettbewerb zurückfallen. 2026 ist nach Einschätzung vieler Beobachter das Jahr, in dem KI im Mittelstand vom Pilotprojekt in den produktiven Dauerbetrieb übergeht. Die entscheidende Frage ist nicht mehr ob, sondern wie sicher. Wer eine KI-Strategie ohne ein begleitendes Sicherheitskonzept aufsetzt, baut auf Sand. Die Geschwindigkeit, mit der sich agentische Systeme einführen lassen, darf nicht zur Geschwindigkeit werden, mit der sich Sicherheitslücken in die Kernprozesse einschleichen.

Bemerkenswert ist auch die zeitliche Dimension: CVE-2026-1470 war nicht die erste kritische Lücke in n8n. Bereits Anfang 2026 waren mehrere Schwachstellen mit Codeausführungs-Potenzial bekannt geworden. Das ist kein spezifischer Vorwurf an n8n – die Plattform ist ein leistungsfähiges, aktiv gepflegtes Open-Source-Projekt, und schnelle Patches sind ein Zeichen von Reife. Es ist vielmehr ein Hinweis darauf, dass die ganze Kategorie der Automatisierungsplattformen unter besonderer Beobachtung steht, weil sie ein so attraktives Ziel darstellt. Wer dort eine Lücke findet, findet nicht eine Anwendung, sondern den Knotenpunkt zu Dutzenden.

Handlungsempfehlungen: Wie der Mittelstand seine Automatisierung absichert

Aus der Külper-Geschichte und der technischen Analyse lassen sich konkrete, übertragbare Maßnahmen ableiten. Sie folgen einem Grundprinzip: Eine Automatisierungsplattform ist kein harmloses Hilfswerkzeug, sondern ein hochprivilegiertes System und muss auch so behandelt werden.

Erstens – Inventarisieren Sie Ihre Automatisierung. Verschaffen Sie sich Klarheit darüber, welche Automatisierungs- und Agenten-Plattformen in Ihrem Unternehmen laufen, wer sie betreibt und – das ist der entscheidende Punkt – welche Zugangsdaten und Berechtigungen sie verwahren. Häufig existieren solche Systeme als Schatten-IT, von einer einzelnen Fachabteilung eingeführt, ohne dass die zentrale IT davon weiß.

Zweitens – Halten Sie die Plattform aktuell. Im konkreten Fall heißt das: n8n auf Version 1.123.17, 2.4.5 oder 2.5.1 beziehungsweise neuer aktualisieren. Grundsätzlich gehören Automatisierungsplattformen in einen geregelten Patch-Prozess mit kurzer Reaktionszeit, weil ihre Lücken so weitreichende Folgen haben. Abonnieren Sie die Sicherheits-Bulletins der eingesetzten Produkte.

Drittens – Nehmen Sie die Plattform aus dem offenen Internet. Eine Automatisierungs-Oberfläche gehört nicht ungeschützt ins Web. Setzen Sie sie hinter ein VPN, einen Reverse-Proxy mit zusätzlicher Authentifizierung oder eine IP-Beschränkung. Wenn einzelne Webhooks von außen erreichbar sein müssen, isolieren Sie diese von der Verwaltungsoberfläche.

Viertens – Minimieren Sie Berechtigungen radikal. Jeder Zugang, den die Plattform verwahrt, sollte nach dem Prinzip der geringsten Rechte eingerichtet sein. Ein Workflow, der nur lesen muss, bekommt keinen Schreibzugriff. Trennen Sie Konten, statt einen Allzweck-Account zu recyceln. Und beschränken Sie konsequent, wer Workflows erstellen und bearbeiten darf – denn genau diese Berechtigung war im Fall CVE-2026-1470 die Eintrittskarte.

Fünftens – Trennen Sie Geheimnisse von der Anwendung. Speichern Sie API-Schlüssel und Passwörter nach Möglichkeit nicht im Klartext innerhalb der Plattform, sondern in einem dedizierten Secrets-Management. So wird ein kompromittierter Automatisierungsserver nicht automatisch zur Fundgrube aller Zugangsdaten.

Sechstens – Überwachen Sie das Verhalten. Külper fiel der Angriff nur deshalb auf, weil jemand zufällig die nächtlichen Ausführungen bemerkte. Etablieren Sie ein systematisches Monitoring: ungewöhnliche Ausführungszeiten, untypische Häufungen, neue oder veränderte Workflows. Ein Alarm bei Anomalien verkürzt die Zeit zwischen Kompromittierung und Entdeckung – und die ist im Ernstfall bares Geld wert.

Siebtens – Behandeln Sie agentische KI mit besonderer Sorgfalt. Wenn ein Sprachmodell eigenständig Werkzeuge aufruft, brauchen Sie klare Leitplanken: Welche Aktionen darf der Agent ohne menschliche Freigabe ausführen, und welche nicht? Bauen Sie Bestätigungsschritte für kritische Operationen ein. Ein Agent, der Rechnungen anweisen oder Daten löschen könnte, gehört an die kurze Leine.

Ausblick: Sicherheit als Voraussetzung, nicht als Bremse

Die Geschichte der Bergischen Verfahrenstechnik Külper GmbH endet nicht mit dem Rückbau der Automatisierung. Im Gegenteil: Tobias Külper und Sven Albrecht haben sich bewusst gegen den Reflex entschieden, das Werkzeug nach dem Schreck abzuschalten. Stattdessen haben sie es neu aufgesetzt – diesmal mit Secrets-Management, segmentierten Berechtigungen, einem geschützten Netzwerksegment und einem Monitoring, das Anomalien meldet. Die Automatisierung läuft heute wieder, sicherer und transparenter als zuvor, und das KI-gestützte Support-Modul ist sogar erweitert worden.

Das ist die eigentliche Lehre aus CVE-2026-1470. Die Antwort auf eine kritische Lücke in einem Automatisierungswerkzeug ist nicht der Verzicht auf Automatisierung, sondern ihre Professionalisierung. Wer KI und Workflow-Automatisierung im Mittelstand erfolgreich einsetzen will, muss Sicherheit von Anfang an mitdenken – nicht als nachträgliche Bremse, sondern als Fundament, das überhaupt erst erlaubt, diese Werkzeuge an sensible Stellen zu lassen.

Bei pleXtec begleiten wir Unternehmen genau an dieser Schnittstelle zwischen Künstlicher Intelligenz, sicherer Softwareentwicklung und belastbarer Informationssicherheit. Die Frage ist nie, ob ein mittelständisches Unternehmen automatisieren oder KI einsetzen sollte – sondern wie es das so tut, dass aus dem Produktivitätsgewinn kein Sicherheitsrisiko wird. Wenn Sie Ihre Automatisierungs- und KI-Landschaft auf den Prüfstand stellen möchten, bevor eine Schwachstelle es für Sie tut, sprechen Sie uns über das Kontaktformular an.

Der nächste Montagmorgen, an dem ein Server ein unerklärliches Eigenleben entwickelt, kommt bestimmt. Die Frage ist nur, ob Sie dann vorbereitet sind – oder ob Sie, wie Sven Albrecht, eine Sicherheitsmeldung erst beim zweiten Lesen ernst nehmen.