CISA warnt vor aktiv ausgenutzter Langflow-RCE

Worum es geht

CISA hat CVE-2026-9198 am 4. August 2026 in den Known Exploited Vulnerabilities Catalog aufgenommen. Das ist kein normales Patch-Hinweisrauschen: Der KEV-Katalog bedeutet, dass die US-Behörde aktive Ausnutzung beobachtet oder belastbar davon ausgeht. Für Bundesbehörden gilt eine schnelle Frist, doch auch private Betreiber sollten den Eintrag als klares Warnsignal lesen.

Die Lücke betrifft Langflow OSS, ein visuelles Werkzeug für KI-Workflows und Agenten. IBM beschreibt die Schwachstelle als vollständige Remote-Codeausführung auf Standardinstallationen. Genau deshalb ist der Fall relevant: Viele Teams behandeln KI-Workflow-Builder noch wie Experimentierwerkzeuge. Sobald sie im Netz erreichbar sind, verhalten sie sich aber wie produktive Ausführungsumgebungen.

Was Langflow tatsächlich macht

Langflow lässt Nutzer Bausteine für Modelle, Prompts, Datenquellen und Tools zu Flows verbinden. In der Praxis entsteht daraus eine Schaltzentrale, die Code, API-Zugriffe und Automatisierung zusammenbringt. Das ist nützlich, weil Entwickler und Fachbereiche schneller testen können, wie ein KI-Prozess arbeitet.

CVE-2026-9198 trifft diese Stärke direkt. Laut IBM konnte ein Angreifer den Endpunkt /api/v1/auto_login nutzen, um ein Superuser-Token zu erhalten. Anschließend ließ sich /api/v1/validate/code missbrauchen, weil dort Benutzercode über exec() ausgeführt wurde. Betroffen sind Versionen 1.0.0 bis 1.10.0; IBM empfiehlt ein Update auf 1.10.1.

Warum das wichtig ist

Der wichtigste Punkt ist nicht nur der CVSS-Wert 9.8. Entscheidend ist die Kombination aus niedriger Einstiegshürde und hoher Wirkung. Ein Dienst, der für KI-Flows gedacht ist, kann in einer Standardkonfiguration zum Einstiegspunkt für Serverkompromittierung werden.

Für echte Teams heißt das: Ein intern schnell gestarteter KI-Baukasten darf nicht einfach mit Default-Einstellungen im Netz stehen. Wer Langflow oder ähnliche Werkzeuge betreibt, muss sie wie CI/CD-Systeme, Notebook-Server oder Admin-Panels behandeln: geschlossen, überwacht, gepatcht und mit klaren Berechtigungen.

Einfach erklärt

Stell dir eine Werkstatt vor, in der jeder Besucher an der Rezeption automatisch den Generalschlüssel bekommt. Danach darf er an einer Prüfstation testen, ob seine Maschine funktioniert. Wenn diese Prüfstation echte Maschinen startet, ist aus einem freundlichen Besucherprozess ein Sicherheitsproblem geworden. Genau diese Art von Vertrauenskette beschreibt IBM bei Langflow.

Praktisches Beispiel

Ein kleines Daten-Team betreibt Langflow für interne Support-Automatisierung. Der Dienst läuft auf einer Cloud-VM, erreichbar über das Internet, weil externe Tester schnell mitarbeiten sollten. Ein Angreifer findet die Instanz, ruft den Auto-Login-Endpunkt auf und erhält ein privilegiertes Token. Danach sendet er Code an den Validierungsendpunkt.

Bei 20 angebundenen Datenquellen, drei API-Schlüsseln und einem Server mit Schreibrechten reicht ein einzelner erfolgreicher Aufruf, um Geheimnisse auszulesen oder weitere Systeme anzutasten. Selbst wenn nur ein Testsystem betroffen ist, können Tokens, Logs und Prompt-Daten produktive Informationen enthalten.

Einordnung und Grenzen

Erstens: Nicht jede Langflow-Installation ist automatisch kompromittiert. Entscheidend sind Version, Konfiguration und Erreichbarkeit.

Zweitens: CISA nennt die bekannte Nutzung in Ransomware-Kampagnen als unbekannt. Der KEV-Eintrag belegt Dringlichkeit, aber nicht automatisch einen bestimmten Angreifer.

Drittens: Der Fall ist kein Argument gegen visuelle KI-Tools. Er ist ein Argument gegen ungehärtete Standarddienste, fehlende Segmentierung und die Annahme, interne Experimente seien ungefährlich.

SEO- und GEO-Schlüsselbegriffe

Langflow, CVE-2026-9198, CISA KEV, IBM Security Bulletin, Remote Code Execution, KI-Workflow, AI Agents, Code Injection, DevOps Security, LLM Security