Langflow CVE-2026-33017: Kritische RCE aktiv ausgenutzt - Bin ich betroffen?

Langflow CVE-2026-33017 ist eine kritische Remote-Code-Execution-Schwachstelle, die besonders für Unternehmen mit selbst betriebenen AI-Workflows brisant ist. Der öffentliche Endpoint /api/v1/build_public_tmp/{flow_id}/flow kann attacker-kontrollierte Flow-Daten akzeptieren, die serverseitig in exec() ohne Sandbox ausgeführt werden.

Noch kritischer ist das Timing: The Hacker News und Sysdig berichten, dass erste Angreifer die Lücke innerhalb von rund 20 Stunden nach der Offenlegung ausgenutzt haben. Wer Langflow für interne Assistenten, Chatbots, RAG-Pipelines oder Agenten mit Zugang zu Datenbanken und API-Keys nutzt, sollte jetzt nicht nur patchen, sondern auch Exposure und Secrets bewerten.

Akute Lage

Die Lage ist akut: Die GitHub Advisory vom 16. März 2026 listet Langflow bis einschließlich 1.8.1 als betroffen und 1.9.0 oder neuer als gepatchte Zielversion. The Hacker News verweist am 20. März 2026 darauf, dass der Fix zu diesem Zeitpunkt bereits in der 1.9.0.dev8-Entwicklungslinie verfügbar war.

• Der betroffene Endpoint /api/v1/build_public_tmp/{flow_id}/flow ist für öffentliche Flows ohne Authentifizierung vorgesehen, akzeptiert aber attacker-kontrollierte data-Payloads, die serverseitig in exec() landen.
• Sysdig beobachtete erste Exploit-Versuche am 18. März 2026 um 16:04 UTC und damit rund 20 Stunden nach der Advisory-Publikation.
• Wenn LANGFLOW_AUTO_LOGIN=true aktiv ist, können Angreifer laut Advisory die Voraussetzungen für den Angriff selbst schaffen, indem sie sich ohne Anmeldung einen Superuser-Token holen und einen Public Flow anlegen.

Was ist passiert?

Laut GitHub Security Advisory liegt der Fehler im Endpoint POST /api/v1/build_public_tmp/{flow_id}/flow. Dieser Endpoint ist explizit für öffentliche Flows ohne Authentifizierung gedacht. Problematisch wird es dadurch, dass optionale data-Payloads nicht nur Eingaben übermitteln, sondern komplette attacker-kontrollierte Flow-Definitionen mit Python-Code enthalten können.

Der technische Pfad ist unangenehm direkt: Die übergebenen Nodes werden beim Build in den Graph übernommen, danach in Custom Components aufgelöst und am Ende über exec(compiled_code, exec_globals) ausgeführt. Entscheidend ist, dass der Code bereits während des Build-Prozesses läuft, also noch bevor der Flow aus Sicht der Betreiber „eigentlich” produktiv gestartet wird.

Inhaltlich erinnert die Schwachstelle an CVE-2025-3248, die 2025 ebenfalls Langflow betraf und später im Zusammenhang mit aktiver Ausnutzung in den Sicherheitsmeldungen rund um CISA KEV auftauchte. Der neue Fall ist laut Advisory jedoch ein anderer Endpoint und zeigt, dass nicht nur eine einzelne Route, sondern ein gesamtes Muster rund um ausführbaren Code in öffentlichen Pfaden problematisch war.

Welche Systeme sind besonders betroffen?

Formell betroffen sind laut Advisory alle Langflow-Versionen bis einschließlich 1.8.1. Operativ gleich kritisch sind aber nicht alle Deployments. Das höchste Risiko besteht dort, wo Langflow aus dem Internet, aus Partnernetzen oder aus breiten internen Zonen erreichbar ist und wo Public Flows genutzt werden.

Besonders wichtig ist die Authentifizierungs-Konfiguration. Die Langflow-Doku warnt ausdrücklich davor, Langflow-Ports direkt ins Internet zu exponieren und empfiehlt LANGFLOW_AUTO_LOGIN=False, einen eigenen LANGFLOW_SECRET_KEY und einen Reverse Proxy mit Authentifizierung. Gleichzeitig beschreibt die Advisory, dass bei AUTO_LOGIN=true die nötigen Voraussetzungen für den Angriff von Angreifern selbst geschaffen werden können.

Betroffenheit pragmatisch prüfen

Inventarisieren Sie alle Self-Hosted-Langflow-Instanzen in Docker, Kubernetes, VM-Umgebungen und Testsystemen. Prüfen Sie Version, Image-Tag, Erreichbarkeit, Public Flows und gespeicherte Secrets. Alles bis einschließlich 1.8.1 sollte als betroffen gelten, bis ein Fix in der genutzten Distribution eingespielt ist.

Wenn Sie nicht schnell genug sagen können, welche Instanzen öffentlich erreichbar sind und wo Langflow produktiv Daten oder Secrets anfassen darf, ist das selbst schon ein Risiko-Signal. Priorisieren Sie exponierte Systeme mit API-Keys, Datenbank-Credentials, Cloud-Tokens und Webhook-Secrets.

Warum ist die Lücke für Unternehmen so kritisch?

Der technische Impact endet nicht bei „irgendwie Codeausführung”. Laut The Hacker News und Sysdig können Angreifer auf betroffenen Instanzen Umgebungsvariablen lesen, Dateien modifizieren, Backdoors ablegen, Datenbank-Zugangsdaten auslesen und weitere Payloads nachladen.

Gerade bei AI-Plattformen ist das kritisch, weil dort oft Modell-Keys, Vektor-Datenbanken, Cloud-Zugangsdaten, Webhooks und Integrationen in den Software-Lieferprozess zusammenlaufen. Ein kompromittiertes Langflow-System ist deshalb nicht nur ein einzelner Server, sondern häufig ein Zugriffspunkt auf mehrere nachgelagerte Systeme.

Hinzu kommt die Geschwindigkeit. Sysdig beschreibt konkret, dass am 17. März 2026 um 20:05 UTC die Advisory veröffentlicht wurde und am 18. März 2026 um 16:04 UTC bereits der erste Exploit-Versuch zu sehen war. Diese kurze Zeitspanne ist für viele interne Patch-, Test- und Freigabeprozesse deutlich zu knapp.

Was jetzt zu tun ist

1. Öffentliche Erreichbarkeit sofort reduzieren

Wenn Langflow direkt aus dem Internet erreichbar ist, sollten Sie zuerst die Angriffsfläche schließen und nicht auf einen späteren Wartungsslot warten. Die Langflow-Dokumentation empfiehlt explizit, Ports nicht direkt öffentlich zu exponieren und stattdessen einen Reverse Proxy mit Authentifizierung zu verwenden.

• Firewall-Regeln schärfen: Port 7860 nicht direkt aus dem Internet erreichbar machen.
• Reverse Proxy davor setzen: zusätzliche Authentifizierung, IP-Allowlisting oder VPN-Zwang.
• Testsysteme nicht vergessen: Demo-, Sandbox- und PoC-Instanzen sind oft die schwächste Stelle.

2. Auf die gefixte 1.9.0-Linie aktualisieren

Die GitHub Advisory nennt 1.9.0 und neuer als gepatcht. The Hacker News verweist am 20. März 2026 auf den Fix in 1.9.0.dev8. Diese Datumsangaben unterscheiden sich, weil die Verfügbarkeit je nach Distribution und Release-Kanal variieren kann. In der Praxis heißt das: Prüfen Sie Ihre konkrete Paket- oder Containerquelle und ziehen Sie die aktuell vom Hersteller ausgewiesene Fix-Version der 1.9.0-Linie vor.

3. Secrets und Integrationen als kompromittiert behandeln

Für öffentlich exponierte und verwundbare Instanzen sollten Sie nicht nur patchen, sondern vorsorglich auch den Secret-Schaden begrenzen. Sysdig sah unter anderem den Versuch, /etc/passwd, Umgebungsvariablen, Konfigurationsdateien und .env-Inhalte auszulesen.

• API-Keys rotieren: LLM-Provider, Vektor-Datenbanken, Webhooks und Drittanbieter-APIs.
• Datenbank-Credentials erneuern: vor allem wenn Langflow produktive Datenquellen anbindet.
• Service-Accounts prüfen: Kubernetes-Secrets, Cloud-Keys, CI/CD-Tokens und Shared Credentials.

4. LANGFLOW_AUTO_LOGIN und Public Flows härten

Selbst wenn Sie kurzfristig noch nicht alle Systeme modernisieren können, sollten Sie die Angriffsbedingungen verschlechtern: automatische Anmeldung deaktivieren, Standard-Zugangsdaten vermeiden, Public Flows auf das absolut notwendige Minimum reduzieren und alte Test-Flows löschen.

IoCs und Monitoring

Laut Sysdig begannen die frühen Angriffe mit automatisierten Scans. Auffällig waren Requests mit dem Cookie-Wert client_id=nuclei-scanner, Flow-Namen wie nuclei-cve-2026-33017 und Outbound-Callbacks an Interactsh-Domains wie .oast.live, .oast.me oder .oast.pro. Spätere Angreifer gingen dann zu individuelleren Recon-Schritten und Stage-2-Payloads über.

Ein fehlender Treffer bedeutet nicht automatisch Entwarnung. Wenn keine aussagekräftigen Logs vorliegen oder Outbound-Verbindungen nicht nachvollziehbar sind, sollten exponierte Systeme konservativ behandelt werden: mögliche Secret-Exponierung annehmen, Integrationen prüfen und Rotationen priorisieren.

Fazit: Langflow jetzt wie eine produktive Angriffsfläche behandeln

CVE-2026-33017 ist kein theoretischer AI-Sonderfall, sondern eine klassische Kombination aus öffentlicher Angriffsfläche, fehlender Authentifizierung und unsandboxed Code-Ausführung. Genau deshalb war die Lücke so schnell operationalisiert.

Für Unternehmen bedeutet das konkret: Langflow nicht als nettes internes Tool behandeln, sondern wie jede andere produktive Plattform mit API-Zugriff, Secrets und Integrationen. Wer heute Version, Erreichbarkeit, Public Flows und Secret-Rotation sauber prüft, reduziert nicht nur das Risiko dieser einen CVE, sondern verbessert die Sicherheitsbasis für Self-Hosted-AI-Workloads insgesamt.

# Docker: laufende Langflow-Container und Image-Tags anzeigen
docker ps --format 'table {{.Names}}\t{{.Image}}\t{{.Ports}}' | grep -i langflow

# Docker: relevante Umgebungsvariablen eines Containers prüfen

docker inspect <container> --format '{{range .Config.Env}}{{println .}}{{end}}' | grep -E 'LANGFLOW_AUTO_LOGIN|LANGFLOW_SECRET_KEY|LANGFLOW_SKIP_AUTH_AUTO_LOGIN'

# Lokaler Listener-Check

ss -ltnp | grep ':7860'

# Kubernetes: Deployments, Images und Umgebungsvariablen sichten
kubectl get deploy,statefulset -A -o wide | grep -i langflow
kubectl get pods -A -o wide | grep -i langflow

# Values/Env in Deployments nach Auth-Parametern durchsuchen

kubectl get deploy -A -o yaml | grep -nE 'langflow|LANGFLOW_AUTO_LOGIN|LANGFLOW_SKIP_AUTH_AUTO_LOGIN|LANGFLOW_SECRET_KEY'

# Beispielhafte Schnellsuche in Logs und Reverse-Proxy-Logs
rg -n "build_public_tmp|/api/v1/auto_login|nuclei-cve-2026-33017|client_id=nuclei-scanner|oast\.(live|me|pro|fun)" /var/log /opt 2>/dev/null

# Docker-Logs einer Langflow-Instanz sichten

docker logs <container> 2>&1 | rg "build_public_tmp|auto_login|client_id|oast\."

# Kubernetes-Logs sichten

kubectl logs -n <namespace> deploy/<langflow-deployment> --since=72h | rg "build_public_tmp|auto_login|client_id|oast\."