Langflow CVE-2026-0768: die zwölfte Langflow-Schwachstelle, die dieses Jahr aktiv ausgenutzt wird

CVE-2026-0768 ist eine nicht authentifizierte Remote-Code-Execution-Schwachstelle in Langflow, dem Open-Source-Framework zur visuellen Zusammenstellung von Pipelines und Agenten für große Sprachmodelle, und bis Ende August 2026 wurde sie von Angreifern in freier Wildbahn ausgenutzt. Die Schwachstelle sitzt im Code-Validator hinter dem Editor für benutzerdefinierte Komponenten von Langflow: Der validate-Endpunkt akzeptiert einen code-Parameter und führt das darin enthaltene Python aus, ohne Authentifizierung und, nach Formulierung der Zero Day Initiative, „im Kontext von root“. Das Canary-Honeypot-Netzwerk von VulnCheck verzeichnete innerhalb von Stunden nach den ersten Erkennungen am 30. August 2026 mehr als 50 Ausnutzungsversuche und bis Montag, den 1. September, mehr als 360, alle gegen Sensoren im Vereinigten Königreich; Caitlin Condon von VulnCheck sagte, der Quellverkehr stamme überwiegend aus Russland. Bei den Anfragen handelte es sich nicht um Ransomware. Sie lasen Umgebungsvariablen aus, die Langflow-Superuser-Anmeldedaten, OpenAI-API-Schlüssel sowie AWS-Zugriffs- und -Geheimschlüssel enthielten, und suchten anschließend nach /root/.cache/langflow/secret_key, .ssh und .bash_history. Der vollständige Eintrag des Archivs zu diesem Vorfall, einschließlich seiner Einstufungen zu Schweregrad, Konfidenz und Schaden, befindet sich in dem Orca AI Incident Archive, zusammen mit den übrigen Einträgen zu Diebstahl von Anmeldedaten und KI-Infrastruktur, die ihn umgeben.

Security Affairs veröffentlichte am 2. September 2026 seinen Bericht; Ionut Arghire von SecurityWeek berichtete am Tag zuvor über die Ausnutzung, Bill Toulas von BleepingComputer befasste sich in dieser Woche damit, und die AI Safety Initiative der Cloud Security Alliance folgte am 4. September mit einer Forschungsnotiz, die den Mechanismus erneut darlegt und Empfehlungen ergänzt. Keine der für diesen Artikel geprüften Darstellungen nannte eine kompromittierte Organisation. Alles geht auf die eigenen Sensoren von VulnCheck und auf die im Januar von der Zero Day Initiative veröffentlichte Sicherheitsmitteilung zurück.

Ein Editor, der ausführt, was er validieren soll

Das Verkaufsargument von Langflow ist, dass man eine KI-Anwendung zusammenstellt, indem man Komponenten auf eine Arbeitsfläche zieht. Benutzerdefinierte Komponenten sind Python: Der Editor ermöglicht es einem Benutzer, Code einzufügen und auf Validieren zu klicken, und der Server prüft ihn. Laut dem ZDI-Advisory ZDI-26-034 wird bei dieser Prüfung der Code ausgeführt. Der Satz zur Grundursache im Advisory besteht aus einer Zeile – „die fehlende ordnungsgemäße Validierung einer vom Benutzer bereitgestellten Zeichenkette, bevor sie zur Ausführung von Python-Code verwendet wird“ – und das Ergebnis ist, dass eine einzige nicht authentifizierte HTTP-Anfrage beliebigen Python-Code auf dem Host ausführt.

Drei Eigenschaften machen daraus einen Sicherheitsvorfall statt eines Fehlerberichts. Der CVSS-Vektor lautet AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H und wird mit 9,8 bewertet: über das Netzwerk erreichbar, geringe Komplexität, keine Berechtigungen, keine Benutzerinteraktion und vollständiger Verlust von Vertraulichkeit, Integrität und Verfügbarkeit. Der Ausführungskontext ist root, weshalb die Angreiferbefehle, die sowohl Condon als auch die Cloud Security Alliance beschreiben, auf /root/.cache/langflow/secret_key abzielen – die Datei, die Langflow zum Verschlüsseln gespeicherter Anmeldeinformationen und Sitzungsdaten verwendet. Und der Endpunkt verlangt überhaupt keine Anmeldeinformationen, sodass die Exposition allein eine Funktion der Erreichbarkeit ist.

Die Historie der Offenlegung ist von Bedeutung dafür, wie sich dies abgespielt hat. ZDIs Zeitlinie verzeichnet, dass der Bericht am 18. Juli 2025 beim GitHub-Konto von Langflow einging, eine Anfrage nach Updates am 11. September 2025, eine Anfrage nach dem Fix am 10. Oktober 2025 und eine Mitteilung über die Absicht, am 10. Dezember 2025 als Zero-Day zu veröffentlichen. ZDI veröffentlichte den Sicherheitshinweis am 9. Januar 2026. Als Forscher genannt werden Peter Girnus, William Gamazo Sanchez und Alfredo Oliveira von Trend Research. GitHubs Advisory-Datenbank enthält denselben Text als GHSA-x5pr-rvjj-j6qm, veröffentlicht am 23. Januar 2026, klassifiziert als CWE-94, und führt überhaupt keinen betroffenen Versionsbereich auf. Die von ZDI angegebene Abhilfemaßnahme ist kein Patch: Sie besteht darin, „die Interaktion mit dem Produkt einzuschränken“.

Öffentliche Berichte verorten den betroffenen Bereich bei Langflow-Versionen bis einschließlich 1.4.2, der Version, gegen die das später hinzugefügte Metasploit-Modul gebaut und getestet wurde. Dort endet die Gewissheit, und der Abschnitt zu den Fixes unten legt dar, warum.

Was 360-Erkennungen belegen und was nicht

Die Canaries von VulnCheck sind mit dem Internet verbundene Sensoren, die so gestaltet sind, dass sie wie das aussehen, wonach ein Angreifer sucht. Das Unternehmen beobachtete am 29.–30. August 2026 die erstmalige Ausnutzung von CVE-2026-0768: mehr als 50 Erkennungen innerhalb weniger Stunden am Sonntag, die bis Montag auf über 360 anstiegen. Condon, Vizepräsident für Bedrohungsforschung bei VulnCheck, beschrieb die Aktivität auf LinkedIn als „eine Mischung aus Aufklärung und Ernte von Zugangsdaten“ und fügte hinzu, dass der Quellverkehr hauptsächlich aus Russland stammte und „bisher ausschließlich Canaries im Vereinigten Königreich getroffen“ habe.

Die vom Sensoren erfasste Befehlsfolge ist spezifisch genug, um als Angriffsplan zu dienen. Angreifer fragten die Umgebung nach LANGFLOW_SUPERUSER ab, nach Variablen, die auf OPENAI_API passen, sowie nach AWS_ACCESS- und AWS_SECRET-Schlüsseln – den drei Zugangsdatenfamilien, die ein Langflow-Host am wahrscheinlichsten enthält. Sie lasen den zwischengespeicherten geheimen Schlüssel unter /root/.cache/langflow/secret_key. Sie prüften den .ssh-Zugriff und untersuchten die Größe von .bash_history; beides deutet darauf hin, ob ein Angreifer sich lateral bewegen kann, statt nur Geheimnisse zu lesen. Ein von der Cloud Security Alliance zitierter Community-Bericht über die Kette ergänzt, dass dieselbe Aktivität Quellbäume und .env-Dateien nach eingebetteten Geheimnissen durchsuchte, die Funde exfiltrierte und prüfte, ob ein Host bereits von einem früheren Angreifer mit einer Backdoor versehen worden war, bevor sie ihre eigene Persistenz hinzufügte.

Was das belegt, ist, dass der Exploit funktioniert, dass er gegen aus dem Internet erreichbare Langflow-Instanzen eingesetzt wurde und dass das Ziel Zugangsdaten und nicht eine Störung war. Was es nicht belegt, ist ein Opfer. Canaries sind Köder; eine Erkennung ist eine Anfrage, kein bestätigter Diebstahl. Das Archiv klassifiziert diesen Datensatz als echten Schaden, und der in den öffentlichen Quellen dokumentierte Schaden ist die bestätigte Ausführung von Code zum Sammeln von Zugangsdaten gegen exponierte Systeme – nicht eine namentlich genannte Organisation, deren Schlüssel verbraucht wurden.

Ein Detail widerspricht der üblichen Geschichte über Offenlegung. Laut VulnCheck existierte kein öffentlicher Proof-of-Concept für CVE-2026-0768, als die Ausnutzung begann. Die Sicherheitsmitteilung war seit fast acht Monaten öffentlich und beschrieb die Schwachstelle präzise genug, dass jemand aus dem Text einen Exploit bauen konnte. Die Einschätzung des Unternehmens, wie von The Hacker News berichtet, ist, dass es sich um eine unabhängige Herleitung und nicht um die Wiederverwendung geleakten Codes handelte.

Zwölf Mängel, fünfzehntausend Versuche – und wo diese Zahlen kippen

Die Statistik, die diesem Vorfall sein Gewicht verleiht, stammt von VulnCheck, und es lohnt sich, sie mit den eigenen Worten des Unternehmens zu zitieren statt sie zu paraphrasieren. „Vor 2026 gab es Hinweise auf nur eine Langflow-Schwachstelle, von der bekannt war, dass sie in freier Wildbahn ausgenutzt wird“, sagte das Unternehmen. „Im Jahr 2026 hat sich vieles schnell verändert.“ SecurityWeek berichtet, dass VulnCheck im Jahr 2026 „11 weitere Schwachstellen verfolgt, die ins Visier genommen und als in freier Wildbahn ausgenutzt gemeldet wurden“.

Zählt man diese hinzu, erhält man zwölf ausgenutzte Langflow-Schwachstellen, von denen eine aus der Zeit vor diesem Jahr stammt. Das ist nicht dasselbe wie zwölf im Jahr 2026, und die Quellen wechseln zwischen den beiden Darstellungen hin und her. Forkasts Schlagzeile bezeichnet CVE-2026-0768 als „Langflows 12. ausgenutzte CVE des Jahres 2026“, während der Text desselben Artikels das Dutzend als „11 neue Schwachstellen und eine, die vor Jahresbeginn identifiziert wurde“ beschreibt. Der Titel des Eintrags folgt der Schlagzeile. Streng gelesen entfallen auf 2026 elf der zwölf, wobei die zwölfte – diejenige, die vor diesem Jahr bekannt war – den Rest ausmacht.

Die Zahl von 15.000 hat einen vergleichbaren Haken. SecurityWeek, The Hacker News und Forkast schreiben „über 15.000 erfolgreiche Angriffe“ drei namentlich genannten Schwachstellen zu: CVE-2026-0769, CVE-2025-3248 und CVE-2026-5027. Das ist eine große Zahl, aber sie ist eine Zählung über drei CVEs, nicht über Langflows gesamtes Portfolio für 2026. Sie als Exploit-Versuche gegen das Portfolio zu formulieren – wie es die Zusammenfassung des Archivs tut –, ist weiter gefasst als das, was VulnCheck veröffentlicht hat.

Die einzelnen Einträge hinter dem Muster sind dokumentiert. CVE-2025-3248 war eine Code-Injection-Schwachstelle im selben /api/v1/validate/code-Endpunkt, die in Langflow 1.3.0 gepatcht wurde, indem die Ausführung durch eine reine Kompilierungsvalidierung ersetzt wurde – laut GitHub-Advisory GHSA-rvqx-wpfh-mfx7, zitiert von der Cloud Security Alliance. Das bedeutet, dass CVE-2026-0768 dieselbe Fehlerklasse im selben Codepfad ist, etwa vier Monate nachdem dieser Fix ausgeliefert wurde. CVE-2026-33017, eine nicht authentifizierte RCE im öffentlichen Flow-Build-Endpunkt, wurde innerhalb von etwa 20 Stunden nach ihrer Offenlegung im März 2026 aktiv ausgenutzt und dazu verwendet, OpenAI-, Anthropic- und AWS-Anmeldedaten zu erbeuten, bevor zu Monero-Cryptomining übergegangen wurde – so die Darstellung der Cloud Security Alliance. Die Notiz derselben Allianz vom 12. Juni 2026 behandelt CVE-2026-5027, eine Path-Traversal-Schwachstelle im Datei-Upload-Endpunkt, die Forschende mit der iranischen staatlich unterstützten Gruppe MuddyWater in Verbindung brachten, und ihre Notiz vom 4. September vermerkt CVE-2026-55255, eine Autorisierungsumgehung, die es einem authentifizierten Benutzer ermöglicht, die Flows eines anderen Benutzers auszuführen; sie wurde am 7. Juli 2026 in den Known Exploited Vulnerabilities-Katalog von CISA aufgenommen. Diese vier teilen eine Gemeinsamkeit: ein Endpunkt, der entweder die Authentifizierung oder die Sanitisierung übersprungen hat, in einer Plattform, deren Aufgabe es ist, Anmeldedaten für alles zu verwahren, mit dem sie kommuniziert.

Warum sich eine Orchestrierungsplattform lohnt

Eine Produktions-Langflow-Instanz ist mit Provider-API-Schlüsseln, Cloud-Anmeldedaten, Datenbank-Verbindungszeichenfolgen und Integrationsgeheimnissen konfiguriert, weil die von ihr ausgeführten Flows sie zur Aufrufzeit benötigen. Eine Kompromittierung des Hosts führt daher zu funktionierendem Zugriff auf jeden Dienst, dessen Anmeldedaten die Instanz speichert. Gestohlene OpenAI- oder Anthropic-Schlüssel ermöglichen es einem Angreifer, Inferenz dem Opfer in Rechnung zu stellen oder sich gegenüber nachgelagerten Stellen als die Organisation auszugeben; gestohlene AWS-Schlüssel öffnen Infrastruktur weit über den Langflow-Container hinaus. Auf diese Hebelwirkung – und nicht auf irgendeine KI-spezifische Fähigkeit – zielten die beobachteten Befehle ab.

Die Einschätzung der Cloud Security Alliance lautet, dass das wiederholte Auftreten in vier verschiedenen Langflow-Subsystemen innerhalb eines einzigen Jahres – Code-Validator, öffentlicher Flow-Build-Endpunkt, Dateiupload, Workflow-Ausführung – auf eine systemische Lücke im Security Engineering hindeutet und nicht auf eine Reihe unzusammenhängender Defekte. Dies ist die Einschätzung der Alliance, vorgelegt in einer Research Note, keine Feststellung eines unabhängigen Prüfers, und Langflow hat in dem hier geprüften Material nicht öffentlich darauf reagiert.

Was wurde behoben, und was ist noch unklar?

Das ist der schwächste Teil der öffentlichen Dokumentation, und es lohnt sich, genau zu benennen, warum. ZDI nennt in seinem Sicherheitshinweis keine gepatchte Version. Der Datenbankeintrag von Snyk für die CVE führt als betroffene Versionen alles vor 1.10.1 auf und empfiehlt ein Upgrade auf 1.10.1 oder höher. Öffentliche Berichte, darunter SecurityWeek und Security Affairs, beschreiben den betroffenen Bereich als Releases bis einschließlich 1.4.2, nennen aber keine Version, in der der Fehler behoben wurde. Die Cloud Security Alliance stellte am 4. September fest, dass die Maintainer von Langflow keinen eigenen Sicherheitshinweis veröffentlicht hatten, der diese CVE nennt, und dass sich die Tracker darüber uneinig waren, welche Release den Fehler tatsächlich behoben hat – eine Unklarheit, die laut der Alliance an einen früheren Langflow-Fall erinnert, in dem eine als behoben gemeldete Version weiterhin ausnutzbar blieb.

Langflow hat durchaus Fixes im richtigen Bereich und am richtigen Tag ausgeliefert. Version 1.11.6 wurde am 1. September 2026 veröffentlicht, dem Montag, an dem der Honigtopf-Zähler 360 überschritt, und in ihren Versionshinweisen wird ein Backport von Sicherheitsfixes beschrieben, darunter „close component code scan gaps“ und „resolve annotations without execution“ (Pull Request 14876). Version 1.12.0 folgte am selben Abend. Die weitere Härtung desselben Codepfads wurde danach fortgesetzt: Ein späterer Pull Request mit dem Titel „stop validate_code from executing imports“ deutet darauf hin, dass der validate-Endpunkt noch Wochen nach der ersten Ausnutzung weiter abgesichert wurde. Nichts davon stellt eine Herstelleraussage dar, dass CVE-2026-0768 in einer benannten Version behoben ist, und in den zitierten Quellen des Eintrags wurde keine solche gefunden.

Was sich auf der Angreiferseite geändert hat, ist klarer. Ein Metasploit-Exploit-Modul für die Schwachstelle wurde am 2. September 2026 als Pull Request eröffnet – am selben Tag, an dem Security Affairs veröffentlichte – und am 8. Oktober 2026 gemergt, getestet gegen Langflow 1.4.2. Unabhängig davon, wie es um die ursprüngliche Herleitung steht, erforderte das Ausnutzen dieser Schwachstelle sechs Wochen nach Beginn ihrer Ausnutzung keine Eigenarbeit mehr.

Die von der Cloud Security Alliance empfohlene Reaktion ist eine Abfolge aus Patchen und Rotieren statt nur Patchen: die laufende Version überprüfen und auf die aktuelle stabile Version wechseln; jede im Internet exponierte Instanz mit einer betroffenen Version als kompromittiert behandeln, bis das Gegenteil bewiesen ist, da die beobachtete Aktivität eine stille Ernte statt einer sichtbaren Störung ist; und jedes Geheimnis rotieren, das die Instanz erreichen konnte – das Langflow-Superuser-Passwort, Provider-API-Schlüssel, AWS-Zugriffs- und -Secret-Schlüssel sowie den Langflow-Secret-Key selbst – und gespeicherte Anmeldedaten neu verschlüsseln, statt lediglich die Datei zu ersetzen. Außerdem wird empfohlen, Zugriffsprotokolle auf Anfragen an den validate-Endpunkt zu prüfen, authorized_keys auf unbekannte SSH-Schlüssel zu kontrollieren und nach Hinweisen zu suchen, dass ein früherer Betreiber den Host bereits mit einer Backdoor versehen hatte. Wo die Plattform erreichbar bleiben muss, wird vorgeschlagen, den validate-Endpunkt durch Zugriffsbeschränkungen zu schützen oder zu deaktivieren und von langlebigen Schlüsseln mit hohen Privilegien, die direkt in der Plattform gespeichert sind, Abstand zu nehmen.

Festgestellt, gemeldet und nicht festgestellt

Festgestellt: dass CVE-2026-0768 eine nicht authentifizierte RCE im validate-Endpunkt von Langflow ist, die Python als root ausführt, dokumentiert in ZDI-26-034 und gespiegelt als GHSA-x5pr-rvjj-j6qm; dass die Ausnutzung am 29.–30. August 2026 begann; dass VulnCheck innerhalb von Stunden mehr als 50 Erkennungen und bis zum 1. September mehr als 360 gegen britische Sensoren verzeichnete, wobei der Datenverkehr überwiegend aus Russland kam; und dass die beobachteten Anfragen auf Langflow-Superuser-, OpenAI- und AWS-Anmeldedaten sowie den zwischengespeicherten geheimen Schlüssel, .ssh und .bash_history abzielten. Diese stammen aus dem Advisory selbst und aus VulnChecks Telemetrie, wie unabhängig von SecurityWeek, Security Affairs und The Hacker News berichtet wurde.

Berichtet, nicht unabhängig verifiziert: jede Erfassungszahl. Die 50, die 360 und die 15.000 sind VulnCheck-eigene Zahlen, vom Unternehmen veröffentlicht und von Medien wiederholt, die es als Quelle nennen; kein zweites Honeypot-Netzwerk hat eine bestätigende Zahl veröffentlicht. Die Zuschreibung zur russischen Infrastruktur ist ebenfalls VulnChecks Lesart des Quellverkehrs, keine Einschätzung, die eine Regierung oder ein CERT in dem geprüften Material bestätigt hat.

Nicht belegt:dass eine namentlich genannte Organisation Zugangsdaten verloren hat. In den Quellen des Datensatzes wurde kein Opfer identifiziert. Ebenso wenig gibt es eine bestätigte gepatchte Version: ZDI nennt keine, Snyk sagt 1.10.1, die Berichterstattung besagt, dass Versionen bis 1.4.2 betroffen sind, und die Versionshinweise zu 1.11.6 beschreiben Sicherheitskorrekturen, ohne sie mit dieser CVE in Verbindung zu bringen. Auch die Zählung „zwölfte Schwachstelle von 2026“ ist über ihre eigenen Quellen hinweg nicht in sich stimmig, wie oben dargelegt.

Der Teil, der Menschen beunruhigen sollte, die nach einem Zeitplan patchen

Die achtmonatige Lücke ist der Befund. CVE-2026-0768 wurde am 9. Januar 2026 als Zero-Day veröffentlicht, mit einer technischen Beschreibung, die detailliert genug war, um die Schwachstelle nachzubauen, und bis zum letzten Augustwochenende geschah nichts gegen die Sensoren von VulnCheck. Dann kamen innerhalb von drei Tagen mehrere hundert Versuche von Angreifern, die nach Darstellung des Unternehmens über keinen öffentlichen Exploit zum Kopieren verfügten. Was auch immer diese Instanzen durch acht Monate einer öffentlichen kritischen Sicherheitsmeldung ungepatcht ließ, ist dasselbe, was die Schwachstelle ausbeutungswert machte, als schließlich jemand den Code schrieb.

Damit schließt sich auch ein Kreis, den die früheren Langflow-CVEs geöffnet haben. CVE-2025-3248 wurde behoben, indem die Ausführung aus demselben Validierungspfad entfernt wurde; CVE-2026-0768 führt auf diesem Pfad trotzdem zur Ausführung. Eine Korrektur, die ein Verhalten entfernt, ohne die Designentscheidung zu entfernen, die es hervorgebracht hat, erkauft Zeit – und in diesem Fall erkaufte sie etwa vier Monate.