Langflow CVE-2026-5027: Wie ein Path Traversal im Datei-Upload und eine unauthentifizierte Auto-Anmeldung exponierte KI-App-Builder zur Remote-Code-Execution führen

TL;DR — 90 Sekunden

Betroffen?

Selbst-gehostete Langflow-Installationen unterhalb 1.9.0, insbesondere wenn sie aus dem Internet erreichbar sind. Die Standardkonfiguration mit aktivierter Auto-Anmeldung (kein Login erzwungen) verschärft die Lage. Censys zählt rund 7.000 öffentlich exponierte Instanzen, mehrheitlich in Nordamerika.

Risiko?

Unauthentifizierte Remote-Code-Execution. Ein Path Traversal im Endpunkt POST /api/v2/files (CVE-2026-5027, CVSS 8.8) schreibt über einen ungeprüften filename-Parameter Dateien an beliebige Stellen des Dateisystems; in Kombination mit der Auto-Anmeldung reicht eine einzige Anfrage ohne Zugangsdaten bis zur Code-Ausführung.

Sofortmaßnahme?

Auf Langflow ≥ 1.9.0 (Release vom 15. April 2026) heben. Bis dahin: die Instanz aus dem offenen Internet nehmen, Authentifizierung erzwingen (LANGFLOW_AUTO_LOGIN=false), den Zugang auf bekannte Quellen einschränken.

Empfehlung?

Mittelstand und Enterprise: jede Langflow-Instanz als produktiven, internetfähigen Dienst behandeln, nicht als internes Bastel-Tool. Erst prüfen, ob überhaupt eine erreichbar ist — die meisten Betreiber unterschätzen genau das.

Kritikalität?

critical (aktive Ausnutzung im Internet seit dem 10. Juni; unauthentifizierter Vektor). Mit ehrlicher Klausel: Der Patch ist seit dem 15. April verfügbar, die bisher beobachteten Payloads schreiben nur Testdateien — der Druck gilt der exponierten, ungepatchten Instanz, nicht der Software an sich.

 

Was ist das Problem?

Langflow ist ein quelloffener, visueller Baukasten, mit dem sich KI-Anwendungen und Agenten per Drag-and-drop zusammenstecken lassen — Prompts, Modelle, Tools und Datenquellen werden zu einem Flow verdrahtet und dann als API bereitgestellt. Genau weil das so bequem ist, landet Langflow häufig schnell auf einem Server und ebenso häufig direkt am offenen Internet. Die Lücke CVE-2026-5027 sitzt im Datei-Upload dieses Dienstes. Tenable, das die Schwachstelle gefunden hat, beschreibt sie nüchtern: Der Endpunkt POST /api/v2/files säubert den filename-Parameter aus dem Multipart-Formular nicht, sodass sich über Path-Traversal-Sequenzen (../) Dateien an beliebige Stellen des Dateisystems schreiben lassen. Das ist eine klassische, seit Jahrzehnten bekannte Schwachstellenklasse — hier gelandet in einer Komponente, die fremde Dateien entgegennimmt und auf der Platte ablegt.

Der zweite Baustein macht die Sache scharf. Langflow aktiviert in der Standardkonfiguration eine unauthentifizierte Auto-Anmeldung: Wer den Dienst erreicht, bekommt ohne Zugangsdaten eine gültige Sitzung. Caitlin Condon von VulnCheck bringt es auf den Punkt: Weil keine Anmeldung erzwungen wird, genügt eine einzige unauthentifizierte Anfrage, um vor der eigentlichen Ausnutzung ein gültiges Session-Token zu erhalten. Aus dem Datei-Schreibzugriff wird so ein vollständiger, vorbedingungsarmer Weg zur Remote-Code-Execution: Ein Angreifer schreibt eine Datei an eine Stelle, von der aus sie ausgeführt oder beim nächsten Start geladen wird, und der Dienst tut den Rest. Der Pfad ist deshalb so gefährlich, weil beide Bausteine — fehlende Eingabeprüfung und fehlender Authentifizierungszwang — in der Standardauslieferung zusammenkommen.

Wichtig für die ehrliche Einordnung: CVE-2026-5027 ist nicht neu entdeckt. Tenable hat die Lücke nach eigener Darstellung im Januar und Februar 2026 dreimal an die Maintainer zu melden versucht und sie am 27. März offengelegt (Advisory TRA-2026-26); behoben wurde sie in Langflow 1.9.0 am 15. April. Frisch ist die Eskalation: VulnCheck beobachtet seit dem 10. Juni aktive Ausnutzung im Internet. Es ist damit kein Zero-Day, sondern ein gepatchter Fehler, der jetzt breit angegriffen wird — die unangenehmste Kategorie für jeden, der das Update verschlafen hat.

Wer ist betroffen?

Die Trennlinie verläuft entlang „exponiert und ungepatcht“. Voll erwischt es selbst-gehostete Instanzen unterhalb 1.9.0, die aus dem offenen Internet erreichbar sind und die Standard-Auto-Anmeldung behalten haben — und das sind nach den Censys-Daten rund 7.000 Stück, mehrheitlich in Nordamerika. Wer Langflow rein intern fährt, hat ein geringeres Akut-Risiko, schließt die Lücke aber mit demselben Update; der Traversal selbst verschwindet nicht dadurch, dass ein Angreifer erst ins Netz muss. Diese Lücke steht außerdem nicht allein: Langflow war 2026 wiederholt Ziel aktiver Ausnutzung, unter anderem über CVE-2026-0770, CVE-2026-33017, CVE-2026-21445 und CVE-2025-34291 — letztere laut Berichten von der staatsnahen Gruppe MuddyWater eingesetzt. Wer eine alte Langflow-Version offen im Netz hat, ist also nicht nur gegen einen einzelnen Fehler exponiert, sondern gegen eine ganze Reihe.

Auswirkungen

Das verlässlich erreichbare Worst-Case-Ergebnis ist Code-Ausführung im Laufzeitkontext des Langflow-Dienstes — und der ist selten harmlos bestückt. Ein KI-App-Builder hält in der Regel API-Schlüssel für die angebundenen Modelle, Tokens für Datenquellen, Datenbank-Zugänge und die Flow-Definitionen selbst, also die Geschäftslogik der gebauten Anwendung. Wer den Dienst übernimmt, erbt diese Berechtigungen. Die bisher beobachtete Ausnutzung ist nach VulnCheck zurückhaltend — geschrieben werden Testdateien, offenbar zur Reichweiten- und Erreichbarkeitsmessung. Das ist die typische erste Welle: Angreifer kartieren, wo der Hebel sitzt, bevor sie ihn nutzen. Aus „nur Testdateien“ wird erfahrungsgemäß schnell mehr, sobald sich Ausnutzung lohnt.

Die ehrliche Einordnung der Schwere: Der CVSS-Wert liegt bei 8.8 (High), nicht bei 9+, und es gibt einen Patch seit zwei Monaten. Was die Lücke trotzdem in die Kategorie critical hebt, ist die Kombination aus unauthentifiziertem Vektor, trivialer Ausnutzbarkeit (eine einzige Anfrage) und aktiver Ausnutzung im Internet bei rund 7.000 erreichbaren Zielen. Censys und VulnCheck zeichnen damit das Bild, vor dem die Branche seit Monaten warnt: Angreifer zielen zunehmend nicht auf die KI-Modelle selbst, sondern auf die Infrastruktur und das Werkzeug, mit dem Organisationen ihre KI-Anwendungen bauen und betreiben. Die Schwachstellenklasse ist uralt; neu ist der Ort, an dem sie wehtut.

Mitigation / Sofortmaßnahmen

Sofort: auf die gepatchte Linie heben

# Python-Installation (pip)
pip install -U "langflow>=1.9.0"

# oder mit uv
uv pip install -U "langflow>=1.9.0"

# Container-Deployment: gepatchtes Image ziehen und Tag pinnen
docker pull langflowai/langflow:1.9.0
# danach Compose-/K8s-Manifest auf >=1.9.0 festziehen und neu ausrollen

# Installierte Version verifizieren
python -m langflow --version
pip show langflow | grep -E 'Name|Version'

Sofort, falls ein Update kurzfristig nicht möglich ist

# 1) Unauthentifizierte Auto-Anmeldung abschalten — nimmt den unauth. Einstieg
export LANGFLOW_AUTO_LOGIN=false
export LANGFLOW_SUPERUSER=<admin>
export LANGFLOW_SUPERUSER_PASSWORD=<starkes-passwort>

# 2) Den Dienst aus dem offenen Internet nehmen:
#    hinter Reverse-Proxy mit Auth, VPN oder IP-Allowlist;
#    nicht direkt auf 0.0.0.0:7860 ins Netz binden.

# 3) Den Upload-Endpunkt am Reverse-Proxy zusätzlich einschränken,
#    wo er nicht gebraucht wird (POST /api/v2/files).

Grundsatz

# Der Patch (>=1.9.0) ist die eigentliche Lösung — er säubert den Dateinamen.
# Auto-Login=false und die Netz-Einschränkung sind Stopgaps, die den
# unauthentifizierten Masseneinstieg nehmen, aber den Traversal nicht
# beheben. Reihenfolge: erst aus dem Netz nehmen / Auth erzwingen,
# dann patchen, dann erst wieder kontrolliert exponieren.

Die Reihenfolge ist hier wichtiger als bei einer rein internen Lücke: Weil aktiv und unauthentifiziert angegriffen wird, zählt die Erreichbarkeit zuerst. Eine Instanz, die niemand von außen erreicht, ist dem Massenscan entzogen, auch bevor das Update läuft. Das Update bleibt Pflicht — aber die offene Tür zuerst zu schließen, kauft die Zeit dafür.

Detection / Prüfung

Bestand feststellen: Läuft hier überhaupt Langflow, und ist es erreichbar?

# Laufende Prozesse / Container
ps aux | grep -i '[l]angflow'
docker ps --format '{{.Image}} {{.Ports}}' | grep -i langflow

# Lauscht der Dienst nach außen? (Standardport 7860)
ss -tlnp | grep -E ':7860'

# In Repos / Manifesten nach Langflow als Abhängigkeit suchen
grep -rniE 'langflow' --include='requirements*.txt' --include='pyproject.toml' \
  --include='docker-compose*.yml' --include='*.yaml' path/to/repos

Version und Konfiguration prüfen

# Versionsstand (Ziel: >= 1.9.0)
python -m langflow --version 2>/dev/null || pip show langflow | grep Version

# Ist die unauthentifizierte Auto-Anmeldung aktiv?
env | grep -i LANGFLOW_AUTO_LOGIN     # leer/true => Standard-Auto-Login aktiv

Spuren der Ausnutzung im Zugriffs-Log suchen

# Auffällige Uploads auf den verwundbaren Endpunkt, vor allem mit
# Traversal-Mustern im Dateinamen (../ bzw. URL-kodiert %2e%2e%2f)
grep -E 'POST /api/v2/files' access.log \
  | grep -Ei '\.\./|%2e%2e'

# Unerwartete neue Dateien außerhalb des Upload-Verzeichnisses
# (Zeitfenster eingrenzen, z. B. seit dem 10.06.); nur auf Test-/Kopien prüfen
find / -newermt '2026-06-10' -type f 2>/dev/null \
  | grep -vE '^/(proc|sys|run)/' | head -100

Wer einen Treffer auf dem verwundbaren Endpunkt mit Traversal-Muster findet, behandelt die Instanz als potenziell kompromittiert: rotieren Sie die in den Flows hinterlegten API-Schlüssel und Tokens und prüfen Sie die geschriebenen Dateien in einer isolierten Umgebung, nicht auf dem Produktivsystem. Abwesenheit von Log-Treffern ist kein Freibrief — viele Standard-Setups loggen den Upload-Body nicht vollständig.

Betreiberempfehlung

Operational Decision Block:

• Sofort handeln (heute), wenn: eine Langflow-Instanz unter 1.9.0 aus dem Internet erreichbar ist — zuerst aus dem offenen Netz nehmen bzw. Authentifizierung erzwingen, dann patchen.
• Im laufenden Patch-Zyklus (diese Woche), wenn: Langflow rein intern läuft, ohne externe Erreichbarkeit — Update einspielen, Auto-Login abschalten, danach Zugriff weiter einschränken.
• Nur verifizieren, wenn: die Instanz bereits auf ≥ 1.9.0 steht, die Auto-Anmeldung deaktiviert ist und kein direkter Internet-Zugang besteht.

Mittelstand

Die erste und wichtigste Frage ist nicht „Welche Version?“, sondern „Steht bei uns überhaupt irgendwo ein Langflow offen im Netz?“. KI-Bau-Tools werden oft von einzelnen Teams schnell aufgesetzt und ebenso schnell vergessen — als Proof of Concept, der dann doch produktiv weiterläuft. Behandeln Sie jede solche Instanz wie einen exponierten Webdienst: Authentifizierung davor, kein direkter Internet-Zugang, regelmäßiges Update. Wer KI-Anwendungen selbst baut, betreibt damit Infrastruktur, nicht nur ein Werkzeug.

Enterprise / mehrere Teams

Per Inventar statt per Stichprobe vorgehen: Langflow taucht in Container-Images, internen Plattformen und Daten-Teams auf, oft ohne zentrale Erfassung. Scannen Sie den eigenen Adressraum gezielt auf den Standardport und den charakteristischen Endpunkt, erfassen Sie Versionsstände über die Image-Registry und erzwingen Sie LANGFLOW_AUTO_LOGIN=false als Policy. Die wiederholte Ausnutzungshistorie von Langflow 2026 macht eine Einzelfall-Betrachtung unangemessen — hier gehört eine dauerhafte Inventar- und Expositionskontrolle hin.

Kubernetes / deklarative Stacks

Gepatchtes Image (≥ 1.9.0) über die Registry ausrollen und per Digest pinnen. Den Dienst nicht über einen öffentlichen Ingress ohne Auth exponieren; NetworkPolicy und ein authentifizierender Reverse-Proxy davor. Daran denken: Ein rollierender Neustart ist nötig, damit die Pods das gepatchte Image tatsächlich laden, und Secrets, die in kompromittierten Flows lagen, gehören rotiert.

Was wir konkret getan haben

Wir haben die Meldung am Tag der Eskalation gegen unseren Bestand geprüft. Die erste Frage war nicht „Welche Langflow-Version?“, sondern „Läuft bei uns oder bei betreuten Plattformen irgendwo eine Langflow-Instanz, und ist sie von außen erreichbar?“. Weil unsere Dienste über Image-Digests und Manifeste inventarisiert sind und der eigene Adressraum regelmäßig auf exponierte Ports gescannt wird, war die Antwort in Minuten da statt per Rundruf. Wo Langflow im Einsatz ist, läuft es hinter erzwungener Authentifizierung und ohne direkten Internet-Zugang, der Versionsstand liegt auf der gepatchten Linie, und die Auto-Anmeldung ist per Policy abgeschaltet.

Der Lesson-Learned ist derselbe, den wir bei der LangGraph-Kette eine Ebene tiefer schon formuliert haben, hier nur an der Außengrenze: Ein KI-Bau-Tool ist kein internes Spielzeug, sondern ein produktiver, internetfähiger Dienst mit privilegierten Secrets im Bauch. Patchen schließt die konkrete Stelle; die dauerhafte Härtung schließt die Klasse — Expositionskontrolle (steht es offen im Netz?), erzwungene Authentifizierung (kein Auto-Login) und Inventarisierung (wissen wir überhaupt, wo es läuft?). Genau hier zahlt sich aus, dass wir selbst-gehostete KI für den Mittelstand als Souveränität bauen und nicht als Bequemlichkeit: Wer den Dienst besitzt, muss ihn als exponierte Identität schützen — und kann es, weil Netz, Zugang und Secrets im eigenen Zugriff liegen.

Fazit

CVE-2026-5027 ist kein exotischer Fehler, sondern eine Lehrbuch-Lücke am genau falschen Ort: ein Path Traversal im Datei-Upload, kombiniert mit einer standardmäßig unauthentifizierten Anmeldung, in einem Werkzeug, das KI-Anwendungen baut und dabei privilegierte Secrets hält. Die Schwere ist ehrlich einzuordnen: CVSS 8.8, ein Patch existiert seit dem 15. April, und die bisher beobachtete Ausnutzung ist zurückhaltend. Was die Lücke dennoch critical macht, ist die Kombination aus unauthentifiziertem Vektor, trivialer Ausnutzbarkeit und aktiver Ausnutzung im Internet bei rund 7.000 erreichbaren Zielen. Wer eine ungepatchte oder offen erreichbare Instanz betreibt, handelt heute; wer Langflow intern und gepatcht fährt, verifiziert nur. Die nachhaltige Lehre liegt nicht in dieser einen Versionsnummer: Ein KI-Bau-Tool ist ein produktiver, internetfähiger Dienst. Patchen schließt die Stelle; Expositionskontrolle, erzwungene Authentifizierung und Inventarisierung schließen die Klasse.

Quellen

• The Hacker News — „Langflow Vulnerability CVE-2026-5027 Exploited for Unauthenticated RCE“ (10.06.2026, Ravie Lakshmanan) — Sekundärquelle, Eskalation/aktive Ausnutzung, VulnCheck- und Tenable-Zitate
• Tenable Research — Advisory TRA-2026-26 (CVE-2026-5027, Langflow Path Traversal) — Primärquelle, technische Beschreibung des Upload-Endpunkts
• NVD — CVE-2026-5027 — CVSS 8.8, Klassifikation Path Traversal
• Langflow 1.9.0 Release Notes (Patch-Version, 15.04.2026) — Fix-Nachweis
• VulnCheck — Hinweis zur aktiven Ausnutzung (Caitlin Condon, LinkedIn) — Quelle der Ausnutzungs- und Auto-Login-Aussage
• Langflow — Projektseite / Dokumentation — Einordnung Funktion und Standardkonfiguration