CISA KEV: Langflow-Lücke CVE-2026-55255 und GhostLock erhöhen Patchdruck

CISA hat wieder zugeschlagen. Drei neue Einträge im Known Exploited Vulnerabilities-Katalog, alle drei mit dem gleichen Muster: erst ignoriert, dann ausgenutzt, jetzt Pflichtprogramm. Die Rede ist von einer kritischen Langflow-Lücke, einem 15 Jahre alten Linux-Kernel-Bug namens GhostLock und einer Prompt-Injection-Schwachstelle mit dem schönen Namen GitLost. Wenig überraschend trifft es damit gleichzeitig die KI-Werkbank und das Fundament darunter. Wer beides betreibt, hat jetzt zwei Baustellen statt einer.

CISA zieht die Patch-Schraube an

Die US-Cybersicherheitsbehörde CISA verpflichtet mit der Aufnahme in den KEV-Katalog zunächst nur Bundesbehörden zum Handeln, im Rahmen der Binding Operational Directive 26-04. Für die Langflow-Schwachstelle CVE-2026-55255 wurde eine Frist bis zum 10. Juli 2026 gesetzt, wie borncity berichtet. Formal betrifft das nur staatliche Stellen in den USA. Praktisch orientieren sich längst auch europäische Unternehmen an diesen Terminen, weil CISA KEV faktisch als Frühwarnsystem für aktiv ausgenutzte Lücken funktioniert, egal wo der Server steht.

Das Pikante daran: CISA KEV-Aufnahmen bedeuten nicht Theorie, sondern bestätigte, laufende Ausnutzung in der Praxis. Wenn eine Schwachstelle hier landet, hat sie den Beweis der Bösartigkeit bereits erbracht. Genau das ist bei allen drei aktuellen Fällen der Fall, mit unterschiedlichen Zielrichtungen: einmal die KI-Automatisierung, einmal der Kernel, einmal die Entwicklerwerkbank.

Die historische Entwicklung des KEV-Katalogs zeigt, dass CISA zunehmend Infrastruktur-Komponenten ins Visier nimmt, die früher unter dem Radar flogen. Noch vor zwei Jahren dominierten klassische Enterprise-Produkte wie Exchange oder VPN-Appliances die Liste. Heute landen dort Plattformen, die viele Teams eher als internes Bastelwerkzeug denn als produktive Infrastruktur einstufen. Wer sich erinnert, wie heftig die Reaktionen waren, als VMware vCenter im CISA-KEV-Katalog bei Admins für Alarmstimmung sorgte, ahnt, welches Potenzial die aktuelle Aufnahme von KI-Orchestrierungstools für die kommenden Monate hat. Der Unterschied: vCenter war als kritische Infrastruktur bekannt. Langflow wurde von vielen Teams noch nie als solche inventarisiert.

Langflow: Wenn die KI-Plattform zur Hintertür wird

Langflow ist eine Open-Source-Plattform zum Bauen von KI-Agenten und Workflows, beliebt bei Teams, die schnell Automatisierungen mit LLM-Anbindung zusammenklicken wollen. Genau diese Beliebtheit macht CVE-2026-55255 brisant. Die Schwachstelle ist ein Authorization Bypass durch eine vom Nutzer kontrollierte Kennung, technisch als CWE-639 katalogisiert. Betroffen sind alle Langflow-Versionen vor 1.9.1, gepatcht wurde mit 1.9.1, wobei mehrere Analysen zusätzlich zum Upgrade auf 1.9.2 oder neuer raten.

Der Exploit-Pfad im Detail

Der Clou der Lücke liegt im Endpoint /api/v1/responses. Ein authentifizierter Angreifer kann dort die Flow-ID eines fremden Nutzers einsetzen und damit dessen Workflow ausführen, ganz ohne Berechtigung dafür zu besitzen. Die Folgen sind unangenehm konkret: Zugriff auf Daten, die dieser fremde Flow verarbeitet, plus die Möglichkeit, seine hinterlegten Aktionen auszulösen, etwa API-Calls oder Cloud-Operationen. Berichten zufolge nutzten Angreifer genau diesen Weg, um LLM-Provider-Keys und AWS-Zugangsdaten aus Langflow-Umgebungen abzugreifen. Wer glaubt, ein internes Tool sei kein attraktives Ziel, wird hier eines Besseren belehrt.

Plot Twist: CVSS 6,1 oder 8,4?

Und hier wird es amtlich absurd. Der offizielle CISA-KEV-Eintrag bewertet CVE-2026-55255 mit einem CVSS-Wert von 6,1. Eine unabhängige technische Analyse kommt für dieselbe Schwachstelle auf 8,4. Das ist keine Randnotiz, das ist ein Unterschied zwischen „mittel“ und „hoch bis kritisch“ in der Priorisierung jedes Patch-Management-Tickets. Sicherheitsforscher argumentieren, dass gerade der Multi-Tenant-Kontext und der mögliche Credential-Diebstahl den praktischen Impact deutlich höher ansetzen sollten als der offizielle Wert. Meine persönliche Einschätzung: Wer sich bei der Priorisierung ausschließlich auf die niedrigere Zahl verlässt, patcht am Ende zu spät. Bemerkenswert ist zudem, dass Langflow damit laut Berichten die erste KI-Agent-Orchestrierungsplattform ist, die es überhaupt in den CISA-KEV-Katalog schafft, wie techtimes.com einordnet. Ein Präzedenzfall, kein Ausrutscher.

GhostLock: 15 Jahre alter Linux-Bug mit Root-Garantie

Während Langflow für Schlagzeilen sorgt, schlummerte GhostLock offenbar seit rund 15 Jahren im Linux-Kernel, unbemerkt oder zumindest ungepatcht. CVE-2026-43499 erlaubt es jedem lokal angemeldeten Nutzer, sich Root-Rechte zu verschaffen. Für sich genommen wäre das schon ärgerlich genug. Der eigentliche Nervenkitzel: In Tests konnte die Schwachstelle die Isolation von Containern umgehen, Angreifer entkamen damit aus ihrer Container-Umgebung heraus auf den Host. Für Kubernetes-Cluster und containerisierte Infrastruktur ist das die Art von Nachricht, die man morgens beim Kaffee lieber nicht liest.

Erschwerend kommt hinzu: Für GhostLock existiert bereits öffentlich verfügbarer Exploit-Code. Das senkt die Einstiegshürde massiv, auch für Angreifer ohne tiefes Kernel-Wissen. Wer schon einmal über kritische Lücken in runc oder containerd gelesen hat, kennt das Grundproblem: Container sind eine organisatorische Grenze, keine physikalische. Ein Kernel-Bug, der Isolation aushebelt, macht aus zehn getrennten Workloads im Ernstfall zehn Türen zum selben Host. GhostLock reiht sich damit in eine wachsende Liste von Linux-Kernel-Rechteausweitungen ein, bei denen öffentliche Exploits lokale Root-Zugriffe erst richtig greifbar machen. Konkrete betroffene Kernel-Versionen variieren je nach Distribution, weshalb der Blick in die jeweiligen Vendor-Advisories von Red Hat, Debian, Ubuntu oder SUSE derzeit Pflichtlektüre für jedes Ops-Team ist, das noch nicht durchgepatcht hat.

Das Host-Flucht-Szenario in der Praxis

Um die Tragweite von GhostLock konkret einzuordnen: In einer typischen Kubernetes-Umgebung mit mehreren Namespaces und unterschiedlichen Tenant-Workloads genügt ein einziger kompromittierter Pod mit lokalem Nutzerzugang, um über den Kernel-Bug auf den Host zu gelangen. Von dort aus stehen dem Angreifer im ungünstigsten Fall alle Secrets, Volumes und Netzwerkverbindungen offen, die der Host verwaltet. Das ist kein theoretisches Übungsszenario, sondern genau die Angriffskette, die bei Penetrationstests regelmäßig als kritischster Befund auftaucht. Die Kombination aus langer Liegezeit des Bugs und öffentlichem Exploit-Code bedeutet, dass Angreifer diese Kette bereits kennen und nutzen, während viele Ops-Teams noch diskutieren, ob ein Kernel-Update gerade in die Sprint-Planung passt. Wer Shared-Cluster betreibt, auf denen Entwicklung, Staging und Produktion laufen, sollte GhostLock nicht als Kernel-Bug behandeln, sondern als Infrastruktur-Notfall.

GitLost: Prompt Injection als Angriffsklasse

Der dritte Fall im Bunde tickt anders. GitLost ist keine klassische Einzel-CVE mit fixer Versionsnummer, sondern eine Angriffsklasse: Prompt-Injection über manipulierte Git-Repositories gegen KI-gestützte Code-Assistenten und GitHub Agentic Workflows. Das Prinzip ist so simpel wie unangenehm. Ein Repository enthält scheinbar harmlosen Code oder Kommentare, die für Menschen bedeutungslos wirken, für einen LLM-Agenten aber als Anweisung gelesen werden. Der Assistent führt aus, was im Repo steht, statt nur das zu tun, was der eigentliche Auftrag vorsah.

Das Grundproblem ist struktureller Natur: Solange KI-Systeme Kontext unkritisch konsumieren, lässt sich über manipulierte Daten praktisch immer ein unerwarteter Befehl einschleusen. Klassischer Signaturschutz greift hier nicht, weil der Schadcode gar keiner ist, sondern reiner Text, der im richtigen Moment zur falschen Anweisung wird. Notwendig wären strikte Trennungen zwischen Daten und Befehlen sowie Sandboxing um LLM-Outputs herum, eine Baustelle, die sich nicht mit einem einzigen Patch schließen lässt. Wer Agentic Workflows produktiv einsetzt und Repositories aus fremden Quellen einbindet, sollte GitLost weniger als Bug und mehr als Dauerzustand begreifen.

Warum GitLost die Lieferkette trifft

Die eigentliche Gefahr von GitLost liegt nicht im einzelnen manipulierten Repository, sondern in der Hebelwirkung auf gesamte Entwicklungspipelines. Moderne CI/CD-Umgebungen binden zunehmend KI-Agenten ein, die automatisch Code-Reviews durchführen, Abhängigkeiten prüfen oder Mergerequests zusammenfassen. Jeder dieser Agenten konsumiert Repository-Inhalte als Kontext. Ein präpariertes Open-Source-Dependency, das in hundert Projekte eingebunden wird, kann damit hundert verschiedene KI-Assistenten gleichzeitig zu unerwünschten Aktionen verleiten: Secrets in Logs schreiben, zusätzliche Commits erzeugen oder Berechtigungen im CI-System erweitern. Dieser Angriffsvektor ist deshalb so tückisch, weil er nicht die Infrastruktur angreift, sondern die Vertrauensannahme, dass Textdaten passiv sind. Wer bislang davon ausging, dass ein Code-Review-Agent im schlimmsten Fall einfach falsche Empfehlungen ausspricht, muss diese Einschätzung jetzt revidieren. Der Agent kann zum aktiven Werkzeug eines externen Angreifers werden, ohne dass ein einziger klassischer Exploit ausgeführt wird.

Der Trend: KI-Frameworks als neue kritische Infrastruktur

Drei Lücken, ein gemeinsamer Nenner: KI-Tooling ist längst keine Randerscheinung mehr, sondern angreifbare Infrastruktur auf Augenhöhe mit Webframeworks oder CI/CD-Systemen. Dass ausgerechnet Langflow als erste Agent-Orchestrierungsplattform im CISA-KEV-Katalog auftaucht, ist ein Symptom, kein Zufall. Frühere Langflow-Schwachstellen, etwa eine kritische Schwachstelle in der Code-Validierung mit hohem CVSS-Wert, die ebenfalls im KEV-Katalog gelandet war, zeigen, dass diese Plattform bereits mehrfach als Einfallstor genutzt wurde. Wer glaubt, mit einem einmaligen Update sei die Sache erledigt, unterschätzt das Muster.

Parallel bleibt die Basis-Infrastruktur verwundbar. GhostLock zeigt, dass Alter kein Schutz ist. Eine Lücke, die 15 Jahre lang unauffällig blieb, kann von einem Tag auf den anderen zum bevorzugten Werkzeug für Privilege Escalation werden, sobald öffentlicher Exploit-Code kursiert. Und GitLost markiert den nächsten Schritt: Angriffe, die nicht mehr auf Code-Schwachstellen zielen, sondern auf die Entscheidungslogik der KI selbst. Die Angriffsfläche wandert von der Maschine zur Interpretation.

Patch-Priorisierung in der Praxis: Ein Entscheidungsrahmen

Angesichts dreier gleichzeitiger Schwachstellen auf völlig unterschiedlichen Ebenen stellt sich die Frage, wo ein begrenztes Ops-Team zuerst ansetzen soll. Eine pragmatische Priorisierung orientiert sich nicht am CVSS-Wert allein, sondern an der Kombination aus Exponiertheit, Ausnutzbarkeit und Schadenspotenzial. GhostLock sollte in jeder Umgebung Priorität eins erhalten, in der lokale Nutzer oder geteilte Container-Workloads existieren. Der Exploit ist öffentlich, die Ausnutzung erfordert keinen Netzwerkzugang und der Schaden ist Root-Zugriff auf den Host. Hier zählt jede Stunde, nicht jeder Sprint.

Langflow bekommt Priorität eins in allen Umgebungen, in denen die Plattform produktiv genutzt wird und LLM-Keys oder Cloud-Credentials hinterlegt sind. Die Credential-Rotation ist hier mindestens so wichtig wie der Patch selbst, weil ein erfolgreicher Exploit bereits stattgefunden haben kann, ohne Spuren in Standard-Monitoring-Systemen zu hinterlassen. GitLost hingegen erfordert keine Sofortpatch-Reaktion, sondern eine strukturelle Anpassung: Sandboxing, Policy-Engines und restriktive Berechtigungen für KI-Agenten, die externe Inhalte verarbeiten. Das ist Arbeit für Wochen, nicht für Stunden, aber sie sollte jetzt beginnen.

Was Unternehmen jetzt tun müssen

Bei Langflow gilt: Version prüfen, mindestens auf 1.9.1 aktualisieren, besser gleich auf 1.9.2 oder neuer. Patchen alleine reicht nicht. Wer eine öffentlich erreichbare Langflow-Instanz betrieben hat, sollte sämtliche gespeicherten LLM-Provider-Keys, Datenbank-Zugangsdaten und Cloud-Tokens rotieren, unabhängig davon, ob eine Kompromittierung nachweisbar ist. Logs nach ungewöhnlichen Requests an den Endpoint /api/v1/responses mit fremden Flow-IDs zu durchsuchen, kostet wenig und bringt Klarheit.

Bei GhostLock führt kein Weg an konsequentem Kernel-Patch-Management vorbei, gerade in Kubernetes-Umgebungen mit Multi-Tenant-Betrieb. Die jeweilige Distribution sollte umgehend auf verfügbare Security-Updates geprüft werden, GhostLock Linux-Schwachstelle-Patches werden je nach Anbieter unterschiedlich schnell ausgerollt. Zusätzlich empfiehlt sich, Container-Isolation nicht als alleinige Sicherheitsgrenze zu behandeln, sondern zusätzliche Kernel-Hardening-Maßnahmen wie Seccomp-Profile oder AppArmor-Regeln ernst zu nehmen. Wer parallel noch offene Baustellen bei runc oder containerd hat, sollte diese jetzt mitpatchen, statt Themen nacheinander abzuarbeiten.

Bei GitLost hilft kein einzelner Patch, sondern ein Prozessumbau: KI-Assistenten, die automatisiert auf Repository-Inhalte reagieren, brauchen eine harte Trennung zwischen ausführbaren Anweisungen und reinem Kontext. Policy-Engines, die Aktionen von Agenten vor der Ausführung gegen definierte Regeln prüfen, sind kein Luxus mehr, sondern Grundausstattung für jedes Team, das Agentic Workflows produktiv nutzt. Externe Repositories sollten grundsätzlich mit geringeren Rechten eingebunden werden als interne, vertrauenswürdige Quellen.

Inventarisierung als blinde Stelle

Ein wiederkehrendes Problem bei Schwachstellen wie der Langflow-Lücke ist, dass viele Unternehmen gar nicht wissen, wo die betroffene Software überall läuft. KI-Werkbanken werden oft von einzelnen Teams oder Data-Science-Abteilungen aufgesetzt, ohne dass die zentrale IT davon erfährt. Shadow-IT trifft auf Shadow-AI. Bevor der Patch greifen kann, muss die Instanz überhaupt erst einmal gefunden werden. Ein kurzfristiger Scan des internen Netzwerks auf Langflow-typische Endpunkte, Standard-Ports und bekannte Container-Images bringt hier schneller Ergebnisse als jede Inventardatenbank. Teams, die diesen Scan jetzt durchführen, werden häufig überrascht sein, wie viele Instanzen auftauchen, die nie offiziell in Betrieb genommen wurden.

Was bleibt?

Drei Lücken, drei völlig unterschiedliche Angriffsflächen, ein gemeinsamer Zeitpunkt im CISA-KEV-Katalog. Das ist kein Zufall, das ist der aktuelle Zustand digitaler Infrastruktur: KI-Werkzeuge, Betriebssystem-Kern und Entwicklerworkflows werden gleichzeitig zur Zielscheibe, weil sie gleichzeitig zur Angriffsfläche geworden sind. Die spannende Frage für die kommenden Monate lautet weniger, ob weitere KI-Plattformen im KEV-Katalog auftauchen, sondern wie schnell Unternehmen lernen, KI-Tooling mit derselben Ernsthaftigkeit zu patchen wie ihre Datenbanken. Bislang sieht es danach nicht aus.

Die Gleichzeitigkeit der drei Schwachstellen erzwingt eine unbequeme Wahrheit: Patch-Management ist längst keine lineare Abarbeitungsliste mehr, sondern ein paralleles Risikomanagement über mehrere Infrastrukturschichten hinweg. Wer_KERNEL-Updates, KI-Plattform-Patches und Prompt-Injection-Prävention als getrennte Themen behandelt, wird in der Summe immer zu spät dran sein. Die Zukunft gehört Teams, die alle drei Ebenen gleichzeitig im Blick haben und ihre Priorisierung dynamisch anpassen, statt auf den nächsten Quartals-Planning-Zyklus zu warten. GhostLock, Langflow und GitLost sind nicht die letzten Schwachstellen dieser Art. Sie sind der Maßstab, an dem sich messen lässt, wer bereit ist.