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

Stand: 20. März 2026 – zuletzt aktualisiert

Autor: Mika Schmidt (IT-Security Consultant) – Six Eight Consulting, Fokus: Analyse, IAM, Security Engineering.

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. [Vendor Advisory]

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. [News] [Threat Research]

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 ubermitteln, sondern komplette attacker-kontrollierte Flow-Definitionen mit Python-Code enthalten können. [Vendor Advisory] [API Docs]

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. [Vendor Advisory]

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. [Vendor Advisory] [Kontext]

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. [Vendor Advisory]

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. [Vendor Docs] [Vendor Advisory]

# 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'
    

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. Ein IT-Security Check bringt hier in kurzer Zeit Klarheit.

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. [News] [Threat Research]

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. [Threat Research]

Was jetzt zu tun ist: priorisierte Sofortmaßnahmen

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. [Vendor Docs]

• Firewall-Regeln scharfen: 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. [Vendor Advisory] [News]

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. [Threat Research]

• API-Keys rotieren: LLM-Provider, Vektor-Datenbanken, Webhooks, 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. [Vendor Docs] [Vendor Advisory]

IoCs und Monitoring: worauf Sie jetzt achten sollten

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. [Threat Research]

# 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\\."
    

Ein fehlender Treffer bedeutet nicht automatisch Entwarnung. Wenn Sie keine aussagekräftigen Logs haben oder Outbound-Verbindungen nicht nachvollziehen können, sollten Sie bei exponierten Systemen lieber konservativ vorgehen und von einer möglichen Secret-Exponierung ausgehen.

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 gesamte Sicherheitsbasis für Self-Hosted-AI-Workloads.

FAQ zu Langflow CVE-2026-33017

Was ist CVE-2026-33017 in Langflow?

CVE-2026-33017 ist eine kritische, unauthentifizierte Remote-Code-Execution-Schwachstelle in Langflow. Der Endpoint /api/v1/build_public_tmp/{flow_id}/flow kann attacker-kontrollierte Flow-Daten verarbeiten, die serverseitig über exec() ohne Sandbox ausgeführt werden.

Welche Langflow-Versionen sind betroffen?

Laut GitHub Security Advisory sind alle Versionen bis einschließlich 1.8.1 betroffen. Als gepatchte Zielversion wird 1.9.0 und neuer genannt. The Hacker News verweist am 20. März 2026 auf einen Fix in 1.9.0.dev8, weshalb Teams die aktuell verfügbare Hersteller-Version in der 1.9.0-Linie prüfen sollten.

Bin ich nur dann akut gefährdet, wenn Langflow öffentlich erreichbar ist?

Das höchste Risiko besteht bei internet-erreichbaren Self-Hosted-Instanzen mit Public Flows. Wenn LANGFLOW_AUTO_LOGIN=true aktiv ist, können Angreifer laut Advisory die nötigen Voraussetzungen teilweise selbst schaffen. Auch intern erreichbare Systeme bleiben kritisch, wenn sie in breiten Netzen oder gemeinsam genutzten Admin-Zonen stehen.

Reicht Patchen allein aus?

Nein. Auf exponierten Instanzen sollten Sie zusätzlich API-Keys, Datenbank-Zugangsdaten und weitere Secrets rotieren, Public Flows prüfen, Logs nach verdächtigen Requests durchsuchen und die Erreichbarkeit dauerhaft per Reverse Proxy, Netzwerksegmentierung und deaktiviertem AUTO_LOGIN absichern.