CVE-2026-9198: Langflow stellte Superuser-Tokens für jedermann aus und führte dann aus, was sie sandten

IBMs Bulletin zu CVE-2026-9198 beschreibt eine Übernahme von Langflow OSS mit zwei Anfragen: Ein Aufruf des Auto-Login-Endpunkts der Plattform gibt jedem, der es anfordert, ein Superuser-Bearer-Token zurück, und eine zweite Anfrage sendet Python an den Code-Validierungs-Endpunkt, der es ausführt. Der Anbieter führt die beiden Hälften der Kette unter getrennten Kennungen auf – CVE-2026-9103 für die fehlende Authentifizierung, CVE-2026-8481 für die Ausführung – und bewertet die Kombination mit 9,8 nach CVSS 3.1, über das Netzwerk ohne Berechtigungen und ohne Benutzerinteraktion erreichbar. Standardbereitstellungen der Versionen 1.0.0 bis 1.10.0 sind betroffen; die Abhilfe ist 1.10.1, und IBM nennt keine Problemumgehung. Die U.S. Cybersecurity and Infrastructure Security Agency hat die CVE am 4. August 2026 in ihren Katalog der Known Exploited Vulnerabilities aufgenommen, mit einer bundesbehördlichen Frist zur Behebung bis zum 7. August. Der Eintrag, seine Schweregrad- und Schadens-Tags sowie die rund um ihn eingereichten Einträge werden im Orca AI Incident Archive, das diesen Vorfall zusammen mit dem Rest der Serie aufführt.

Die Kette, in drei IBM-Bulletins

IBM veröffentlicht diese Schwachstelle in drei Dokumenten statt in einem, und erst das gemeinsame Lesen macht den Mechanismus verständlich. Die gesamte Kette ist CVE-2026-9198, ein Code-Injection-Problem unter CWE-94, mit 9,8 bewertet und mit dem Vektor AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H — über das Netzwerk erreichbar, geringe Komplexität, keine Privilegien, keine Benutzerinteraktion und hohe Auswirkungen auf Vertraulichkeit, Integrität und Verfügbarkeit. Bei ihrer ersten Hälfte, CVE-2026-9103, handelt es sich um eine fehlende Authentifizierung für eine kritische Funktion unter CWE-306, ebenfalls mit 9,8 bewertet. Bei ihrer zweiten Hälfte, CVE-2026-8481, handelt es sich erneut um CWE-94, aber mit 9,9 bewertet: AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H, geringe Privilegien statt gar keine sowie ein geänderter Scope.

Die 9,9 ist der ehrliche Teil der Rechnung. Der Endpunkt zur Codevalidierung war nie von sich aus für Fremde offen — IBM beschreibt ihn als Schwachstelle, die es jedem authentifizierten Benutzer ermöglichte, beliebige Systembefehle mit den vollen Privilegien des Langflow-Serverprozesses auszuführen. Was die Kette unauthentifiziert macht, ist die erste Hälfte: der Auto-Login-Endpunkt, der laut IBM „langlebige Superuser-Bearer-Tokens ausgibt, ohne Authentifizierung zu verlangen, wenn die AUTO_LOGIN-Konfiguration aktiviert ist (standardmäßig aktiviert)“. Das Bulletin ergänzt, dass die Tokens eine Lebensdauer von 365 Tagen haben, und dokumentiert einen zweiten Angriffsweg, der weniger Beachtung findet — permissive Standardeinstellungen für Cross-Origin Resource Sharing, die Wildcard-Origins mit Anmeldedaten zulassen, was laut IBM „Drive-by-Token-Diebstahl von beliebigen Websites ermöglichen könnte“.

Der Ausführungsteil ist der Teil, auf den man näher eingehen sollte. In der Zusammenfassung von IBM heißt es, der Validator habe „vom Benutzer übermittelten Code kompiliert und ausgeführt, einschließlich Auswertungen zur Funktionsdefinitionszeit wie Standardargumente und Dekoratoren“, und ein Angreifer könne daher einen ausführbaren Ausdruck in einen Standardparameter oder einen Dekorator einschmuggeln. Das ist keine Redewendung in Bezug auf unsicheren Code: Ein Dekorator wird ausgewertet, wenn das umgebende def konstruiert wird, sodass eine Anfrage, deren einzig angegebener Zweck darin besteht, die Syntax einer Funktion zu prüfen, dennoch alles ausführt, was daran angehängt ist. IBMs eigener verketteter Sicherheitshinweis sagt in einem einzigen Satzteil genau das aus – Validierung und Ausführung waren derselbe Vorgang. Die im Bulletin CVE-2026-8481 dokumentierte Korrektur bestand darin, „die Codeausführung aus dem Validierungspfad zu entfernen und nur Kompilierungsprüfungen durchzuführen“.

Eine kleine Abweichung ist es wert, festgehalten zu werden, weil sie das Hunting beeinflusst. Das verkettete Bulletin schreibt den Token-Endpunkt als /api/v1/auto_login, und ebenso die Cloud Security Alliance und Field Effect; IBMs separates Bulletin zu CVE-2026-9103 schreibt ihn als /api/v1/login/auto_login. Beide IBM-Dokumente beschreiben denselben Endpunkt, und keines davon liegt in Bezug auf das Verhalten falsch. Der Ausführungspfad wird überall identisch angegeben: POST /api/v1/validate/code.

Woher die Datumsangaben stammen

Das Archiv datiert diesen Datensatz auf den 6. August 2026. CISA-Katalogeintrag, gelesen am 30. Oktober 2026, verzeichnet die Aufnahme als 4. August 2026 und setzt die Frist für die Behebung auf den 7. August. Die umliegende Berichterstattung liegt auf beiden Seiten des Archivdatums statt auf diesem selbst: Field Effect veröffentlichte am 5. August, und cvetodo sowie das nationale Computer-Notfallteam Thailands veröffentlichten beide am 7. August. Ein Listeneintrag, die daraus entstehende Frist und die darüber verfassten Artikel sind drei verschiedene Ereignisse, daher widersprechen sich diese Daten nicht — aber die zweitägige Lücke zwischen dem Feld des Archivs und dem von CISA ist der Grund, den Katalog zu lesen, wenn der genaue Tag zählt.

Die Offenlegung ist schwieriger genau zu bestimmen, und die Quellen widersprechen sich tatsächlich. IBMs Bulletin-Seite für die verkettete CVE nennt als Erstveröffentlichungsdatum den 2. Juli 2026 und als Änderungsdatum den 17. August 2026. Field Effect datiert IBMs Offenlegung auf den 2. Juli. Die Forschungsnotiz der Cloud Security Alliance vom 18. August setzt die Offenlegung und die Veröffentlichung von 1.10.1 zusammen damit auf den 17. Juli; cvetodo sagt dasselbe. Fünfzehn Tage trennen die beiden Lesarten, und keines der Dokumente ist nachlässig, daher entscheidet sich dieser Artikel nicht zwischen ihnen. Was in jedem Fall feststeht, ist, dass der Patch vor der KEV-Auflistung veröffentlicht wurde und dass 1.10.1 die Version ist, die ihn enthielt.

Was der CISA-Eintrag in seinen eigenen Feldern genau besagt, ist enger gefasst als seine Überschrift. Das Produkt ist unter dem Anbieter IBM mit dem Produkt Langflow aufgeführt; die Schwachstelle wird als eine beschrieben, „die nicht authentifizierten Angreifern ermöglicht, vollständige Remote-Code-Ausführung auf Standard-Langflow-Bereitstellungen zu erreichen“; die bekannte Nutzung in Ransomware-Kampagnen ist als Unbekannt verzeichnet; forensische Triage ist unter BOD 26-04 als erforderlich gekennzeichnet; und die erforderliche Maßnahme besteht darin, Minderungsmaßnahmen gemäß den Anbieteranweisungen anzuwenden oder die Nutzung des Produkts einzustellen, wenn keine Minderungsmaßnahmen verfügbar sind.

Der Ausbeutungsdatensatz

Die Listung von CISA behauptet, dass die Schwachstelle in freier Wildbahn ausgenutzt wurde. Die öffentlichen Belege hinter dieser Behauptung sind dünner, als es die 9,8 vermuten lässt. Weder IBM noch CISA haben einen Bedrohungsakteur genannt oder Details einer beobachteten Kampagne veröffentlicht – Field Effect erklärt dies ausdrücklich, und nichts in den drei IBM-Bulletins oder dem KEV-Eintrag widerspricht dem.

Was stattdessen vorliegt, ist aus zweiter Hand weitergegebene Anbieter-Telemetrie. Die Mitteilung der Cloud Security Alliance führt KEVIntel für die Behauptung an, dass Ausnutzungsversuche beginnend „etwa um den 6. Juli 2026 herum“ verzeichnet worden seien – Wochen vor der Offenlegung nach eigener Berechnung der Allianz – und dass bis Mitte August die kumulierten Versuche auf Hunderte angestiegen seien, ausgehend von mehreren hundert eindeutigen Internetadressen, die über Dutzende Länder verteilt waren. Diese Zahlen stammen von einem einzigen Überwachungsunternehmen und erscheinen in keiner anderen für diesen Artikel geprüften Quelle. Sie werden hier berichtet, nicht bestätigt.

Das Startdatum ist einen zweiten Blick wert. Wenn die Versuche tatsächlich um den 6. Juli begannen, liegt das vier Tage nach dem Datum des Bulletins, das die IBM-Seite angibt, und elf Tage vor dem 17. Juli, den zwei andere Quellen nennen. Die Telemetrie bestätigt daher keines der beiden Offenlegungsdaten und widerlegt auch keines; die Cloud Security Alliance bietet beide Erklärungen an, ohne sich zu entscheiden, und beschreibt die frühe Aktivität entweder als unabhängige Entdeckung durch opportunistische Scanner oder als Durchsickern technischer Details vor der koordinierten Offenlegung.

Öffentlicher Exploit-Code ist der besser dokumentierte Teil. Field Effect schreibt die öffentliche Beschreibung der Angriffskette einem „öffentlichen Proof-of-Concept, das im Juli 2026 veröffentlicht wurde“, im Repository github.com/0xdak/CVE-2026-9198_exploit zu und erklärt, der Code demonstriere, wie man über den Auto-Login-Endpunkt ein Superuser-Token erlangt und dieses dann gegen den Validierungsendpunkt verwendet. Field Effect bringt den Autor dieses Repositorys nicht mit einer beobachteten Ausbeutung in Verbindung, und dieser Artikel ebenso wenig. Auch keine der geprüften Quellen berichtet über einen bestätigten Diebstahl von Zugangsdaten aus einem ausgebeuteten Host: Die Beschreibung der Sammlung von Zugangsdaten, die Langflow-Schwachstellen allgemein begleitet, ist eine Einschätzung dazu, was ein solcher Host enthält – weiter unten behandelt –, und keine Feststellung zu einem in diesem Bericht genannten Opfer.

Festgestellt, gemeldet und nicht festgestellt

• Bestätigt. Dass CVE-2026-9198 fehlende Authentifizierung im Auto-Login-Endpunkt mit Codeausführung im Code-Validierungs-Endpunkt verkettet; dass IBM die Kette unter CWE-94 mit 9,8 bewertet und ihre beiden Hälften mit 9,8 und 9,9; dass Standardbereitstellungen von Langflow OSS 1.0.0 bis 1.10.0 unter Windows, macOS und Linux betroffen sind; dass 1.10.1 die Behebung ist und IBM keine Problemumgehung veröffentlicht; und dass CISA die CVE in den KEV-Katalog aufgenommen hat, mit einer Frist für Bundesbehörden bis zum 7. August 2026. Die drei IBM-Bulletins sind die Primärdokumente, und sie stimmen hinsichtlich des Mechanismus überein.

• Unabhängig wiedergegeben. ThaiCERT reproduzierte in seinem Sicherheitshinweis vom 7. August 2026 dieselbe Zwei-Endpunkt-Kette, dieselbe Bewertung von 9,8, denselben betroffenen Bereich und dieselbe 1.10.1-Lösung und ergänzte eine Netzwerkkontrolle, die die IBM-Bulletins nicht enthalten: Die Administrationsoberfläche von Langflow nicht aus dem öffentlichen Internet erreichbar zu halten und nur über ein VPN oder eine strikte Adress-Allowlist darauf zuzugreifen. Das ist eine Bestätigung dafür, wie der Sicherheitshinweis gelesen wurde – durch eine staatliche Stelle, die kein Eigeninteresse an der Formulierung des Anbieters hat – und keine unabhängige Entdeckung der Schwachstelle.

• Berichtet, nicht bestätigt.Jede Angabe zur Ausnutzung: Hunderte Versuche, mehrere hundert Adressen, Dutzende Länder, ab etwa dem 6. Juli. Dies sind die Zahlen eines einzelnen Überwachungsunternehmens, weitergegeben von einer Forschungseinrichtung. Die Auflistung von CISA bestätigt, dass eine Ausnutzung stattfand, ohne sie zu quantifizieren, und im hier geprüften Material taucht keine zweite Telemetriequelle auf.

• Nicht belegt. Kein benanntes Opfer und kein benannter Akteur. Keine Zuschreibung an einen Staat oder an eine kriminelle Gruppe. Keine bestätigte Zahl dazu, wie viele Langflow-Instanzen über das Internet erreichbar waren – cvetodo berichtete am 7. August, dass IBM Fragen zum Ausmaß der Ausnutzung nicht beantwortet hatte – und seitdem liegt keine Herstellererklärung vor, die das quantifiziert. Das Archiv stuft diesen Eintrag mit Vertrauensstufe A ein und kennzeichnet ihn nicht als umstritten, und keines der hier geprüften Dokumente stellt ihn in Frage; die Lücken sind Lücken in den öffentlichen Belegen, nicht in der Behauptung, dass die Schwachstelle existiert und ausgenutzt wurde.

• Bewusst ausgeschlossen.Die Warnmeldung von ThaiCERT beschreibt ebenfalls KI-gesteuertes automatisiertes Scannen in derselben Woche, ordnet es jedoch einem anderen Produkt im selben CISA-Paket zu, nicht Langflow. Sie ist kein Beleg für diesen Datensatz und wird hier nicht als solcher verwendet.

Was hat sich nach dem Listing geändert?

Die Abhilfe des Herstellers besteht in einem Versionssprung und sonst nichts. Die Tabelle der betroffenen Produkte von IBM listet Langflow OSS 1.0.0 bis 1.10.0 auf, nennt 1.10.1 als Fix und setzt „None“ in das Feld für Problemumgehungen – in allen drei Bulletins. Das Bulletin zu CVE-2026-8481 beschreibt die Änderung: Der Validator ging von der Ausführung zur Kompilierung über. Das Bulletin zu CVE-2026-9103, das die Auto-Login-Hälfte abdeckt, erläutert seine Korrektur nicht in derselben Ausführlichkeit, und kein hier geprüftes IBM-Dokument gibt ein Datum für die Veröffentlichung von 1.10.1 an.

Die Empfehlungen aller anderen gehen weiter als die des Anbieters. Die Cloud Security Alliance empfiehlt, ein Upgrade durchzuführen und dann zur Laufzeit zu überprüfen, dass der Auto-Login-Endpunkt keine Tokens mehr an nicht authentifizierte Aufrufer ausgibt, statt der Versionszeichenfolge zu vertrauen – als angegebenen Grund nennt sie, dass frühere Langflow-Patches mit unvollständigen Fixes ausgeliefert wurden. Außerdem empfiehlt sie, die Umgebungseinstellung LANGFLOW_AUTO_LOGIN explizit auf false zu setzen, damit die Plattform echte Zugangsdaten verlangt, statt solche zu erzeugen, und jede Instanz, die seit Anfang Juli aus dem Internet erreichbar war, bis zur Überprüfung der Protokolle als kompromittiert zu behandeln, wobei die Zugangsdaten für alles rotiert werden sollten, was die Instanz erreichen konnte: Schlüssel von Modellanbietern, Datenbank-Zugangsdaten und Cloud-Service-Schlüssel. ThaiCERT ergänzt den Netzwerkaspekt – keine administrative Oberfläche im öffentlichen Internet, nur VPN oder Positivliste. Beides sind Empfehlungen der Forscher. IBM veröffentlicht keine.

Eine Anerkennung ist öffentlich verzeichnet. In IBMs Danksagung wird der Bericht Harish Kolla zugeschrieben, GitHub-Handle Har1sh-k. Die Cloud Security Alliance ordnet CVE-2026-9198 in ihrer Notiz vom 18. August als vierte eigenständige Langflow-Schwachstelle ein, die ohne Authentifizierung ausgenutzt werden kann oder eine Autorisierungsumgehung darstellt und innerhalb von rund fünf Monaten in den CISA-Katalog gelangt ist; dabei nennt sie die drei früheren Kennungen. Ihre Deutung ist, dass das Muster wiederholte, stückweise Behebungen eines einheitlichen Authentifizierungs- und Codeausführungsmodells widerspiegelt und nicht voneinander unabhängige Defekte. Diese Einordnung ist die Einschätzung der Alliance, vorgelegt in einer Forschungsnotiz; sie ist kein Befund eines unabhängigen Prüfers, und keine hier gesichtete Quelle dokumentiert eine öffentliche Reaktion der Maintainer darauf.

Was die KEV-Auflistung klärt und was nicht

Der CISA-Katalog ist eine Aussage über beobachtete Ausnutzung, kein Vorfallbericht, und dieser Eintrag bleibt dieser Form treu. Er besagt, dass die Schwachstelle ausgenutzt wurde; er sagt nicht, gegen wen, von wem oder wie oft. Der Ransomware-Einsatz ist als „Unbekannt“ verzeichnet. Nichts wird quantifiziert. Was der Eintrag jedoch klärt, ist die eine Frage, die eine Schweregradbewertung nicht beantworten kann: ob die Schwachstelle von einem funktionierenden Proof of Concept zu tatsächlicher Nutzung übergegangen ist. Für Organisationen außerhalb des Geltungsbereichs von BOD 26-04 – also für den Großteil der Welt – begründet die Frist vom 7. August keine Verpflichtung, und die dahinterstehende Tatsache wiegt genauso schwer, wie sie es mit einer Verpflichtung getan hätte.

Die Cloud Security Alliance zieht aus demselben Eintrag die operative Schlussfolgerung: dass eine KEV-Listung ein zuverlässiges Signal dafür ist, dass die Ausnutzung das Proof-of-Concept-Stadium überschritten hat, und dass sie bei dieser Schwachstelle etwa einen Monat nach den ersten verzeichneten Versuchen erfolgte. Wer mit der Triage wartete, bis der Katalog vorlag, reagierte dieser Lesart zufolge bereits auf einen Vorfall, statt einen zu verhindern. Ob dies auf eine bestimmte Bereitstellung zutrifft, ist eine Frage für deren Protokolle – das Endpunktpaar, nach dem gesucht werden muss, ist das von IBM dokumentierte, und der Datensatz nennt kein einziges Opfer, an dem sich die Antwort überprüfen ließe.