Was passiert ist
Die US-Cybersicherheitsbehörde CISA hat die Schwachstelle CVE-2026-9198 am Dienstag, dem 4. August 2026, in ihren Katalog der bekannten ausgenutzten Schwachstellen aufgenommen. Grundlage dafür sind Hinweise auf aktive Angriffe. Betroffen ist Langflow, eine visuelle Low-Code-Plattform zum Bau von KI-Agenten und RAG-Workflows, also Abläufen, bei denen ein Sprachmodell auf eigene Dokumente und Datenquellen zugreift.
Die Lücke erlaubt es unauthentifizierten Angreifern, aus der Ferne beliebigen Code auf verwundbaren Systemen auszuführen. Betroffen sind laut IBM die Standard-Installationen von Langflow OSS in den Versionen 1.0.0 bis 1.10.0. Wer eine solche Instanz im Netz betreibt, sollte umgehend auf Version 1.10.1 oder neuer aktualisieren. Aktuell steht Version 1.11.2 bereit.
Zwei Fehler, die zusammen zur Übernahme führen
Der Angriff verkettet zwei Schwächen der Standardkonfiguration. Erstens gibt es einen Auto-Login-Endpunkt, der jedem Aufrufer aus dem Netz ein Superuser-Token ausstellt. Zweitens existiert ein Endpunkt zur Code-Validierung, der übergebenen Python-Code schlicht ausführt.
In Kombination genügt das, um die Kontrolle über den Langflow-Server zu übernehmen. Von dort aus liegt der Weg zu angebundenen Systemen, API-Schlüsseln und Datenquellen offen, denn genau diese Verbindungen sind der Zweck der Plattform. Ein kompromittierter Workflow-Server ist damit potenziell ein Einstiegspunkt in die gesamte KI-Infrastruktur eines Unternehmens.
Auffällig ist das Tempo: Die CVE wurde am 17. Juli 2026 veröffentlicht. Keine drei Wochen später lagen der CISA Belege für aktive Ausnutzung vor. Wie viele Systeme weltweit oder im DACH-Raum tatsächlich kompromittiert wurden, ist nicht bekannt.
Die Eckdaten im Überblick
| Punkt | Angabe |
|---|---|
| Kennung | CVE-2026-9198 |
| Veröffentlichung der CVE | 17. Juli 2026 |
| Aufnahme in den CISA-Katalog | 4. August 2026 |
| Betroffene Versionen | Langflow OSS 1.0.0 bis 1.10.0 |
| Behoben ab | Version 1.10.1 |
| Aktuelle Version | 1.11.2 |
| Angriffsart | Codeausführung aus der Ferne, ohne Anmeldung |
Wie Langflow zu IBM kam
Langflow stammt ursprünglich von Logspace. DataStax übernahm das Projekt 2024, IBM kaufte DataStax und damit auch Langflow im Jahr 2025. Seitdem ist die Plattform als Middleware in watsonx.ai eingebunden, IBMs Entwicklungsumgebung für KI-Anwendungen.
Ob und in welchem Umfang von IBM selbst gehostete watsonx.ai-Dienste betroffen waren, ist offen. Belegt ist bislang nur, dass sich die Warnung auf Standard-Installationen von Langflow OSS bezieht, also auf Instanzen, die Unternehmen selbst betreiben.
Was das für Unternehmen bedeutet
Der Fall ist kein Argument gegen Open Source, aber ein sehr klares Argument gegen unbedachte Standardkonfigurationen. Wer selbst hostet, spart Lizenzkosten und vermeidet die Abhängigkeit von einem Anbieter, übernimmt dafür aber Patch-Management, Netzsegmentierung und Härtung in Eigenregie. Diese Arbeit lässt sich nicht wegdelegieren.
Eine Standard-Installation, die ungehärtet im Netz erreichbar ist, ist keine Kostenersparnis, sondern eine offene Tür.
Praktisch heißt das: Auto-Login in produktiven Umgebungen deaktivieren, Verwaltungs- und Validierungsendpunkte nicht frei erreichbar machen und ein Inventar darüber führen, welche KI-Werkzeuge im Unternehmen überhaupt laufen. Gerade Tools zum Bau von Agenten entstehen oft in Fachabteilungen, ohne dass die IT davon weiß.
Dass Agenten-Infrastruktur zunehmend ins Visier gerät, zeigen auch andere Vorfälle der vergangenen Monate, etwa als KI-Agenten Open-Source-Projekte auf GitHub attackierten. Parallel verlagern Anbieter Sicherheitsarbeit selbst in Richtung Automatisierung, so hat Cloudflare eingekaufte Security-Tools durch eigene KI-Agenten ersetzt. Wer KI-Workflows lieber in einer Umgebung mit klaren Grenzen laufen lässt, findet mit Ansätzen wie Cloudflare OS als Arbeitsumgebung für KI-Agenten eine Alternative zu offen erreichbaren Eigeninstallationen.
Für Teams im DACH-Raum gilt dieselbe Prüfliste wie überall: Version feststellen, aktualisieren, Logs auf ungewöhnliche Aufrufe der betroffenen Endpunkte durchsehen und Zugangsdaten rotieren, die auf der Instanz hinterlegt waren. Bei Systemen, die personenbezogene Daten verarbeiten, kommt zusätzlich die Frage nach einer meldepflichtigen Datenpanne ins Spiel.