Langflow CVE-2026-0770: exec_globals erlaubt unauthentifizierte RCE — zweite Langflow-Lücke in CISA KEV, kein Patch in Sicht

TL;DR — 90 Sekunden

Betroffen?

Jede Langflow-Instanz mit Netzwerkzugriff auf /api/v1/validate/code. Laut GitHub Advisory Database sind Versionen bis einschließlich 1.7.3 gelistet (nach anderen Trackern ab 0.0.31, rund 280 Versions-Tags) — ob neuere Releases (aktuell 1.9.3) tatsächlich gefixt sind, ist nicht bestätigt.

Risiko?

Unauthentifizierte Remote-Code-Execution (CVSS 8.9 nach CVSS 4.0 / 9.8 nach CVSS 3.0), typischerweise mit root-Rechten im Container. Aktiv ausgenutzt seit ca. 27.06.2026, laut KEVIntel über 220 Exploit-Versuche von 64 unterschiedlichen IPs.

Sofortmaßnahme?

Netzwerkzugriff auf /api/v1/validate/code sofort einschränken oder die Instanz ganz vom offenen Internet nehmen — es gibt keinen Versions-Patch, auf den stattdessen aktualisiert werden könnte.

Empfehlung?

Historische Zugriffe auf den validate/code-Endpoint prüfen, Host-Aktivität auf Recon- und Second-Stage-Muster untersuchen, alle vom Langflow-Host erreichbaren Secrets als potenziell kompromittiert behandeln und rotieren.

Kritikalität?

kritisch (Hero-Badge) — unauthentifiziert, volle RCE, aktive Ausnutzung, CISA-KEV-Eintrag, kein bestätigter Patch.

Was ist das Problem?

Langflow ist ein visueller Builder für KI-Agenten-Workflows, der unter anderem einen /api/v1/validate/code-Endpoint bereitstellt, mit dem Nutzer im Frontend Python-Snippets für eigene Custom Components auf Syntaxfehler prüfen können. Diese Validierung ist serverseitig in der Funktion validate_code() implementiert. Das Problem: Die Funktion nimmt neben dem zu prüfenden Code auch einen Parameter exec_globals entgegen und reicht dessen Inhalt ungefiltert an Pythons eingebaute exec()-Funktion weiter. exec() führt beliebigen Python-Code im übergebenen Namensraum aus — wer den Inhalt von exec_globals kontrolliert, kontrolliert damit auch, was auf dem Server ausgeführt wird. Da der Endpoint keine Authentifizierung verlangt, kann jeder Angreifer mit Netzwerkzugriff auf die Instanz beliebigen Code einschleusen — mit den Rechten des Langflow-Prozesses, in vielen Container-Images root.

Die Schwachstelle ist als CWE-829 („Inclusion of Functionality from Untrusted Control Sphere“) klassifiziert und wurde am 18.07.2025 an den Hersteller gemeldet. Laut Zero Day Initiative blieb eine Reaktion über Monate aus (Nachfragen am 11.09.2025 und 10.10.2025, Ankündigung der 0-Day-Veröffentlichung am 10.12.2025); die öffentliche Advisory folgte am 09.01.2026 (ZDI-26-036) bzw. 22.–23.01.2026 (NVD/GitHub Advisory Database), zuletzt aktualisiert am 19.02.2026. Die ZDI-Advisory selbst hält fest, dass die „einzig sinnvolle Gegenmaßnahme“ die Einschränkung der Interaktion mit dem Produkt sei — ein impliziter Hinweis darauf, dass zum Zeitpunkt der Veröffentlichung kein Fix vorlag.

Wichtig zur Einordnung: Das ist eine andere Schwachstelle als das bereits auf diesem Blog behandelte CVE-2026-55255 (IDOR, authentifizierte Cross-Tenant-Flow-Ausführung) und CVE-2026-5027 (Path Traversal im Datei-Upload). Alle drei betreffen dieselbe Plattform, sind aber technisch unabhängige Fehler.

Wer ist betroffen?

CISA hat die Lücke am 21.07.2026 in den KEV-Katalog aufgenommen — ein starkes Signal für bereits laufende, aktive Ausnutzung und nicht nur theoretisches Risiko. Das threat-intel-Unternehmen KEVIntel beobachtete erste Angriffe bereits ab ca. 27.06.2026, mit über 220 Exploit-Versuchen von 64 unterschiedlichen IPs bis zur KEV-Aufnahme.

Auswirkungen

Der unmittelbare Impact ist vollständige Remote-Code-Execution ohne jede Authentifizierung — in der Praxis der schlimmste Fall, den eine Web-Anwendung erleiden kann. Da der Langflow-Prozess in vielen Deployments mit root-Rechten im Container läuft, erhält ein Angreifer effektiv volle Kontrolle über den Host bzw. Container: Lesen und Schreiben beliebiger Dateien, Start beliebiger Prozesse, Zugriff auf alle Umgebungsvariablen und damit auf sämtliche in Langflow konfigurierten API-Keys, Datenbank-Zugangsdaten und Cloud-Credentials. Laut den vom Threat-Intel-Anbieter KEVIntel dokumentierten Angriffen umfasste die beobachtete Post-Exploitation-Aktivität unter anderem Command-Execution-Checks zur Verifikation der Lücke, System-Reconnaissance, das Nachladen von Second-Stage-Skripten sowie das gezielte Abgreifen von Zugangsdaten und Cloud-Metadaten (u. a. AWS-Credentials).

Da Langflow häufig als Orchestrierungsschicht für KI-Agenten mit Zugriff auf nachgelagerte Systeme, Datenbanken und externe APIs dient, reicht der Blast-Radius potenziell weit über die Langflow-Instanz selbst hinaus: Jedes Secret, das ein kompromittierter Langflow-Host erreichen konnte, muss als potenziell abgeflossen gelten — unabhängig davon, ob sich ein konkreter Missbrauch im Nachhinein nachweisen lässt.

Mitigation / Sofortmassnahmen

Hinweis: Nach aktuellem Kenntnisstand existiert kein vom Hersteller bestätigter Patch für CVE-2026-0770. Die folgenden Schritte konzentrieren sich daher auf Zugriffsbeschränkung, Monitoring und Schadensbegrenzung statt auf ein Versions-Update — prüfen Sie vor Umsetzung gegen die aktuellen Langflow-Security-Advisories, ob sich der Stand geändert hat.

Operativer Entscheidungsblock

• Heute handeln, wenn … Ihre Langflow-Instanz aus dem Internet oder einem nicht vertrauenswürdigen internen Netz erreichbar ist und Sie den Zugriff auf /api/v1/validate/code nicht bereits eingeschränkt haben.
• Mit Priorität prüfen, wenn … Sie US-Bundesbehörde oder Zulieferer sind — CISAs Meldefrist für diese KEV-Aufnahme lag bei 24.07.2026.
• Nur beobachten, wenn … Ihre Instanz nachweislich keinerlei Netzwerkzugriff von außerhalb eines eng kontrollierten, vertrauenswürdigen Segments erlaubt.

Schritt 1 — Zugriff auf den verwundbaren Endpoint einschränken

# Netzwerkzugriff auf die Langflow-Instanz auf vertrauenswürdige Quellen begrenzen (Firewall/Security Group)
# Reverse Proxy mit erzwungener Authentifizierung vor die Instanz schalten,
# insbesondere fuer /api/v1/validate/code
# Falls die Code-Validierungsfunktion nicht zwingend benoetigt wird:
# Route auf Reverse-Proxy-Ebene blocken, z.B. mit nginx:
location /api/v1/validate/code {
    deny all;
    return 403;
}

Schritt 2 — Host- und Log-Review

# historische Zugriffe auf den validate-Endpoint pruefen (siehe Detection-Abschnitt)
# laufende und kuerzlich beendete Prozesse des Langflow-Dienstes auf unbekannte Kindprozesse pruefen
ps auxf | grep -i langflow
# ausgehende Verbindungen des Langflow-Hosts auf unbekannte Ziele pruefen (potentielle Second-Stage-Downloads)
ss -tnp | grep langflow

Schritt 3 — Zugangsdaten rotieren

# alle Secrets rotieren, die vom Langflow-Host oder von dort erreichbaren Umgebungen aus zugreifbar waren:
# - API-Keys fuer LLM-Provider und sonstige Drittdienste
# - Datenbank-Zugangsdaten
# - Cloud-Credentials (AWS/GCP/Azure), insbesondere falls Instance-Metadata-Service erreichbar war
# - lokale Zugriffstoken/SSH-Keys auf dem Host

Schritt 4 — falls kein Patch absehbar ist

# Instanz vollstaendig aus dem oeffentlichen Netz nehmen, bis ein Fix bestaetigt ist
# alternativ: Zugriff ausschliesslich ueber VPN/Zero-Trust-Zugang mit Authentifizierung erlauben
# Monitoring/Alerting auf erneute Zugriffsversuche auf /api/v1/validate/code einrichten

Detection / Prüfung

Version und Erreichbarkeit prüfen

pip show langflow | grep Version
docker inspect <container> | grep -i langflow
# pruefen, ob der Endpoint ueberhaupt von aussen erreichbar ist
curl -s -o /dev/null -w "%{http_code}\n" <host>/api/v1/validate/code -X POST

Historische Zugriffe auf den verwundbaren Endpoint pruefen

# Access-/Reverse-Proxy-Logs auf Requests gegen den validate-Endpoint durchsuchen
grep "api/v1/validate/code" access.log | awk '{print $1, $4, $7}' | sort -u
# verdaechtige Payload-Inhalte im Request-Body identifizieren
grep -E "exec_globals|__import__|os\.system|subprocess|base64\.b64decode" access.log

Host-seitige Indikatoren

# unerwartete Kindprozesse des Langflow-Dienstes
ps auxf | grep -i langflow
# Zugriffe auf die Cloud-Metadata-Instanz (typisches Ziel bei Credential-Harvesting)
grep "169.254.169.254" outbound.log
# ungewoehnliche ausgehende Verbindungen kurz nach Requests an validate/code
ss -tnp | grep langflow

Laufzeit-Indikatoren

• POST-Requests an /api/v1/validate/code von unbekannten oder unerwarteten Quell-IPs, insbesondere ohne vorherige Authentifizierung
• Prozessstarts durch den Langflow-Dienstnutzer, die keinem bekannten Langflow-Subprozess entsprechen
• Nachladen externer Skripte/Binaries durch den Langflow-Prozess (Second-Stage-Deployment)
• Zugriffe auf Umgebungsvariablen, Credential-Dateien oder den Cloud-Metadata-Endpoint kurz nach Requests an den validate-Endpoint

Betreiberempfehlung

Mid-Market

Prüfen Sie umgehend, ob Ihre Langflow-Instanz überhaupt aus dem Internet oder einem nicht vertrauenswürdigen Netz erreichbar ist. Falls ja: Zugriff auf /api/v1/validate/code sofort blocken oder hinter eine Authentifizierung legen, historische Logs prüfen und alle vom Host erreichbaren Secrets rotieren — unabhängig davon, ob ein Missbrauch nachweisbar ist. Ein Versions-Update allein reicht derzeit nicht als Maßnahme, da kein bestätigter Fix existiert.

Enterprise

Zusätzlich: Container-Härtung prüfen (Langflow-Prozess nicht als root betreiben, wo immer möglich), Netzwerksegmentierung so gestalten, dass die Instanz keinen unnötigen Zugriff auf den Cloud-Metadata-Service oder interne Systeme hat, und Secrets-Management auf externe Stores mit kurzlebigen, scope-begrenzten Tokens umstellen statt Credentials direkt in der Umgebung des Langflow-Hosts vorzuhalten. Bei mehreren Langflow-Instanzen: zentrales Monitoring auf die in diesem Beitrag genannten Indikatoren aufsetzen.

US-Bundesbehörden / regulierte Umgebungen

Der CISA-KEV-Eintrag vom 21.07.2026 ist Teil eines Sechs-Schwachstellen-Updates über den 21.–22.07.2026 und bringt für Bundesbehörden eine verbindliche Meldefrist (24.07.2026) im Rahmen von CISAs BOD-22-01-Programm mit sich — auch als Zulieferer relevant, falls vertragliche Compliance-Anforderungen bestehen.

Entscheidungsblock

Heute handeln, wenn: Langflow-Instanz erreichbar, kein Zugriffsschutz auf den validate-Endpoint, kein Nachweis, dass keine Ausnutzung stattfand. Beobachten, wenn: Zugriff bereits strikt eingeschränkt und Logs unauffällig.

Fazit

CVE-2026-0770 ist ein Lehrbuchbeispiel dafür, wie gefährlich es ist, Nutzereingaben ungefiltert in exec() zu reichen — verstärkt dadurch, dass der betroffene Endpoint keinerlei Authentifizierung verlangt und in vielen Deployments mit root-Rechten läuft. Dass die Lücke bereits sechs Monate vor der öffentlichen Advisory gemeldet wurde und laut ZDI ohne Herstellerreaktion blieb, bevor sie als 0-Day veröffentlicht wurde, ist ebenso bemerkenswert wie der Umstand, dass über ein halbes Jahr später — trotz aktiver Ausnutzung und CISA-KEV-Eintrag — kein bestätigter Patch existiert. Das ist Langflows zweite Schwachstelle im KEV-Katalog innerhalb weniger Wochen. Wer die Plattform betreibt, sollte nicht auf ein Versions-Update warten, sondern den Netzwerkzugriff auf sicherheitsrelevante Endpoints grundsätzlich einschränken und Secrets so verwalten, dass die Kompromittierung eines einzelnen Dienstes nicht automatisch zur Kompromittierung der gesamten Umgebung führt.

Quellen

• GitHub Advisory Database — GHSA-g22f-v6f7-2hrh: Langflow affected by Remote Code Execution via validate_code() exec()
• NVD — CVE-2026-0770 Detail
• Zero Day Initiative — ZDI-26-036 (ZDI-CAN-27325)
• CISA — CISA Adds Four Known Exploited Vulnerabilities to Catalog (21.07.2026)
• Security Affairs — U.S. CISA adds DD-WRT, Langflow and WordPress flaws to its KEV catalog
• BleepingComputer — CISA orders urgent action on actively exploited Langflow RCE flaw
• Corgea — CVE-2026-0770 vulnerability details (affected version range)
• langflow-ai/langflow — GitHub Releases (Patch-Status-Abgleich)