Was ist Langflow, und warum betrifft das so viele?

Langflow ist eine quelloffene, visuelle Plattform zum Bauen von Workflows rund um große Sprachmodelle: Nutzer:innen ziehen Bausteine für Prompts, Datenquellen, Tools und eigene Python-Komponenten auf eine Oberfläche und verbinden sie zu lauffähigen Pipelines oder Agenten. Ursprünglich bei DataStax entstanden, wird das Projekt inzwischen mit Beteiligung von IBM weiterentwickelt und läuft unter der Bezeichnung „IBM Langflow OSS“. Die Einstiegshürde ist bewusst niedrig gehalten: Eine Installation ist in wenigen Minuten per Docker-Container oder pip-Paket lauffähig, oft auf einem Test- oder Demo-Server, gelegentlich auch produktiv mit Anbindung an interne Datenquellen, APIs oder Zugangsdaten für andere Dienste. Genau diese Kombination aus schneller Verbreitung, häufig experimentellen Deployments und potenziell weitreichenden Zugriffsrechten macht Schwachstellen in Langflow überdurchschnittlich brisant: Ein kompromittierter Server ist selten nur ein isoliertes Test-Setup, sondern hat oft Zugriff auf API-Schlüssel für Sprachmodelle, Datenbanken oder andere angebundene Systeme.

Der erste Schritt: eine Login-Abkürzung ohne Prüfung

Der erste Baustein der Kette ist der Endpunkt /api/v1/auto_login. Er war als Komfortfunktion gedacht: In Umgebungen, in denen kein separates Anmeldesystem gewünscht ist – etwa lokale Entwicklung oder einzelne Demo-Instanzen –, sollte er automatisch eine gültige Sitzung bereitstellen, ohne dass jemand Zugangsdaten eingeben muss. In den betroffenen Versionen 1.0.0 bis 1.10.0 fehlte dabei eine ausreichende Prüfung, unter welchen Bedingungen das geschehen darf. Jeder Client, der die Route per GET oder POST über das Netzwerk ansprach, erhielt ein gültiges JSON-Web-Token – und zwar nicht mit eingeschränkten Rechten, sondern mit der Rolle SUPERUSER, der höchsten Berechtigungsstufe in Langflow. Für einen Angreifer bedeutet das: keine Zugangsdaten erraten, keine Session kapern, keine Schwachstelle im eigentlichen Sinne eines Speicherfehlers ausnutzen – nur eine einzige, unautorisierte HTTP-Anfrage an eine Route, die vermutlich nie öffentlich erreichbar sein sollte.

Der zweite Schritt: ein Endpunkt, der Code einfach ausführt

Der zweite Baustein, /api/v1/validate/code, ist an sich eine dokumentierte und im normalen Betrieb nützliche Funktion: Weil Nutzer:innen in Langflow eigene Python-Komponenten schreiben können, bietet die Plattform eine Möglichkeit, deren Code vorab auf Syntaxfehler zu prüfen. Technisch geschieht das, indem der eingereichte Code direkt per Python-Funktion exec() im Serverprozess ausgeführt wird – ein Vorgehen, das nur so lange vertretbar ist, wie ausschließlich vertrauenswürdige, authentifizierte Nutzer:innen mit entsprechend eingeschränkten Rechten darauf zugreifen können. Genau diese Voraussetzung war durch den ersten Schritt der Kette hinfällig: Mit einem über auto_login erschlichenen SUPERUSER-Token ist validate/code aus Sicht der Anwendung ein völlig legitimer Aufruf. Der Server unterscheidet nicht zwischen einem echten, berechtigten Entwickler und einem Angreifer, der Sekunden zuvor ein Token ohne jede Prüfung erhalten hat. Was als Komfortfunktion für Code-Validierung gedacht war, wird so zur direkten Codeausführungs-Schnittstelle für jeden, der die vorgeschaltete Tür passiert hat.

Die Kette im Ganzen: von der offenen Tür zur vollen Kontrolle

In der Praxis genügen damit zwei aufeinanderfolgende HTTP-Anfragen ohne jegliche Zugangsdaten: eine an auto_login, um ein Token zu erhalten, eine zweite an validate/code mit dem eigentlichen Angriffscode im Gepäck. Die Ausführung erfolgt im selben Prozess wie der Langflow-Server selbst, mit dessen Rechten. Bei containerisierten Deployments – der in der Praxis häufigsten Betriebsform – bedeutet das typischerweise Zugriff auf alle im Container hinterlegten Umgebungsvariablen, API-Schlüssel für angebundene Sprachmodelle oder Datenquellen sowie auf das Dateisystem des Containers; von dort aus sind je nach Konfiguration weitere Schritte zur Ausbreitung im Netzwerk denkbar. Bei einer Installation direkt auf einem Server ohne Container-Isolation reicht die potenzielle Auswirkung entsprechend weiter. Mit einem CVSS-Basiswert von 9.8 – dem oberen Ende der Skala – ordnen sowohl der Hersteller als auch mehrere unabhängige Sicherheitsdienste die Lücke als kritisch ein.

Wie stark wird die Lücke bereits ausgenutzt?

Wie stark CVE-2026-9198 bereits ausgenutzt wird, lässt sich nur über Telemetriedaten spezialisierter Dienste einschätzen, nicht über eine einzelne autoritative Zahl. Der Tracking-Dienst KEVIntel registrierte nach eigenen Angaben rund 650 Ausnutzungsversuche von 244 unterschiedlichen IP-Adressen aus 41 Ländern – ein Hinweis auf breit gestreute, wahrscheinlich automatisierte Scan- und Exploit-Aktivität statt eines gezielten Einzelangriffs. Bemerkenswert und in den vorliegenden Quellen nicht abschließend geklärt: Die gezählten Versuche beginnen bereits am 6. Juli 2026 – vor dem Datum, das mehrheitlich als Tag der öffentlichen Offenlegung genannt wird. Für Betreiber:innen heißt das in der Praxis: Wer eine öffentlich erreichbare, ungepatchte Langflow-Instanz betrieben hat, sollte nicht nur patchen, sondern auch prüfen, ob es bereits vor dem eigenen Update-Zeitpunkt Zugriffsversuche oder gar erfolgreiche Zugriffe gegeben hat – ein reines Update beseitigt den Zugangsweg, aber nicht die Folgen einer bereits erfolgten Kompromittierung.

Reaktion von IBM und CISA: Patch und Bundesfrist

IBM hat nach übereinstimmenden Berichten mehrerer Fachmedien die Lücke am 17. Juli 2026 offengelegt und mit Version 1.10.1 zeitgleich behoben: auto_login vergibt seither keine Superuser-Rechte mehr an unauthentifizierte Anfragen, und validate/code führt eingereichten Code nicht mehr ungeprüft aus. Rund drei Wochen später, am 4. August 2026, nahm die US-Cybersicherheitsbehörde CISA die Schwachstelle zusammen mit einer Lücke in Apache Tomcat (CVE-2026-34486) und einer bereits zuvor bekannten Schwachstelle in der Fernwartungssoftware N-able N-central in ihren Known-Exploited-Vulnerabilities-Katalog auf – ein klares Signal, dass es sich nicht mehr um ein theoretisches Risiko handelt. Auf Basis der Binding Operational Directive 26-04 mussten US-Bundesbehörden betroffene Systeme bis zum 7. August 2026 patchen oder vom Netz nehmen und zusätzlich prüfen, ob vor dem Patch bereits eine Kompromittierung stattgefunden hatte – eine Vorgabe, die sich sinngemäß auch für alle anderen Betreiber:innen empfiehlt.

Kein Einzelfall: Langflows Geschichte mit demselben Endpunkt

CVE-2026-9198 ist nicht die erste kritische Codeausführungs-Lücke in Langflow, und der Endpunkt validate/code nicht zum ersten Mal betroffen: Bereits 2025 wurde ein Weg bekannt, über den unauthentifizierte Anfragen an genau diesen Endpunkt zu Codeausführung führten; die damalige Lücke wurde mit Version 1.3.0 geschlossen. Auch danach folgten weitere, technisch unabhängige RCE-Meldungen für andere Endpunkte, etwa über den öffentlichen Flow-Build-Mechanismus (CVE-2026-33017, behoben in Version 1.9.0). CVE-2026-9198 zeigt damit weniger eine einzelne vergessene Prüfung als ein wiederkehrendes Muster: Ein Endpunkt, der Nutzer-Code ausführt, ist nur so sicher wie jeder einzelne Weg, ihn zu erreichen – und mit auto_login kam schlicht ein neuer, unautorisierter Weg dorthin hinzu, nachdem der direkte Zugang bereits geschlossen worden war.

Was Betreiber:innen jetzt tun sollten

Wer Langflow selbst betreibt, sollte mehrere Schritte in dieser Reihenfolge angehen. Erstens, sofort auf Version 1.10.1 oder neuer aktualisieren – das schließt beide Enden der Kette. Zweitens, vor dem Update in Zugriffs- und Anwendungs-Logs nach Aufrufen von /api/v1/auto_login und /api/v1/validate/code suchen, insbesondere nach unerwarteten Zugriffen ohne vorherige reguläre Anmeldung; solche Funde deuten auf einen möglichen Kompromittierungsversuch hin und rechtfertigen eine tiefere forensische Prüfung. Drittens, unabhängig vom Patch-Status grundsätzlich prüfen, ob die Langflow-Instanz überhaupt öffentlich aus dem Internet erreichbar sein muss – für die meisten Entwicklungs- und internen Anwendungsfälle reicht ein Zugriff ausschließlich aus internen, vertrauenswürdigen Netzen über VPN oder Reverse Proxy mit eigener Authentifizierung völlig aus. Viertens, verwendete API-Schlüssel und Zugangsdaten, die der Langflow-Instanz zugänglich waren, im Zweifel rotieren, wenn ein Zugriffsversuch nicht ausgeschlossen werden kann. Bewusst nicht Teil dieses Artikels ist eine Schritt-für-Schritt-Anleitung zur Ausnutzung der Kette – die technischen Hintergründe dienen dem Verständnis der Risikoeinschätzung und der Härtung, nicht als Vorlage für Angriffe.

Einordnung: ein Muster bei schnell wachsender KI-Infrastruktur

Der Fall reiht sich in eine wachsende Zahl kritischer Schwachstellen in KI-Infrastruktur-Software ein, die 2026 unter aktivem Beschuss stand – von Agenten-Plattformen bis zu Werkzeugen für Sprachmodell-Workflows. Gemeinsamer Nenner ist oft dasselbe Grundproblem wie hier: Funktionen, die für schnelle Einrichtung und einfache Bedienung gedacht waren – ein automatischer Login, eine bequeme Code-Ausführung zu Testzwecken –, wurden nicht konsequent genug gegen unautorisierten Zugriff von außen abgesichert. Je mehr Organisationen solche Werkzeuge im Eiltempo produktiv einsetzen, desto wichtiger wird es, Komfortfunktionen mit demselben kritischen Blick zu behandeln wie jede andere Authentifizierungsschicht auch. Wer KI-Workflow-Plattformen betreibt, sollte deren Angriffsfläche so bewusst einschränken wie die eines jeden anderen produktionsnahen Systems – und nicht davon ausgehen, dass eine für Entwicklungszwecke gedachte Abkürzung niemals von außen erreichbar sein wird.

Anzeige
#Security