flawopen.com/Teardowns/cve-2026-5027-langflow-multipart-file-write
Langflow CVE-2026-5027: Pfadtraversal beim Datei-Upload
CVE-2026-5027 erlaubte Path Traversal und Schreiben außerhalb von Langflows Upload-Ordner. GTIG meldet Ausnutzung; Update auf 1.9.0+.[1], [2], [6]
Eine Poststelle nimmt ein Paket an, dessen Absender Etikett und Zielort bestimmt. Verknüpft der Angestellte das Etikett mit dem Poststellenordner, ohne den fertigen Pfad zu prüfen, kann das Paket außerhalb landen. Langflows Upload-Route vertraute dem Multipart-Dateinamen; die Speicherschicht prüfte nicht zusätzlich, ob der Zielpfad im erlaubten Ordner blieb.[2], [3]
Kernkonzepte & Begriffe
CVE-2026-5027- Von Tenable vergebene Kennung für Path Traversal im Multipart-Dateinamen von Langflows POST /api/v2/files:
CWE-22, CVSS 3.1 8,8 und geringe erforderliche Rechte.[1], [2] Multipart-Dateiname- Vom Client gelieferter Name im Content-Disposition-Header eines Multipart-Uploads. Er ist nicht vertrauenswürdige Eingabe, kein sicherer Dateipfad.[1], [2]
Framework-Zuordnungen
- CWE-Referenz für die in diesem Leitfaden beschriebene Schwachstelle: CWE-22
Ursachenanalyse
Tenable beschreibt für CVE-2026-5027, dass POST /api/v2/files einen Multipart-Dateinamen mit Traversal-Komponenten akzeptiert und außerhalb des vorgesehenen Ordners schreibt. Die Sicherheitsgrenze umfasst API-Route und lokalen Speicher: URL-Parameter zu validieren prüft keinen Namen aus Multipart-Content-Disposition; das Anhängen an einen Ordner belegt keine Pfadbegrenzung. Der CVE-Vektor verlangt geringe Rechte (PR:L); behaupten Sie keinen Authentifizierungs-Bypass durch die CVE selbst. Google GTIG führt CVE-2026-5027 unter bestätigten In-the-Wild-Ausnutzungen, belegt im öffentlichen Kurztext aber keine allgemeine Codeausführung. Beliebiges Schreiben kann je nach beschreibbaren Pfaden, Prozessrechten und Konfiguration schwerwiegender sein; behandeln Sie das als bedingte Auswirkung, nicht als garantiertes RCE. Langflows zugehöriges GHSA nennt CVE-2026-33309 und verweist ebenfalls auf die Korrektur in 1.9.0. Dieser Artikel folgt CVE-2026-5027 nach Tenable und GTIG und macht die abweichende Kennung transparent. Der gemergte Langflow-Patch validiert Namen auf API-Ebene und erzwingt kanonische Pfadbegrenzung im Speicher, auch vor dem Anlegen von Verzeichnissen.[1], [2], [3], [4], [5], [6]
Schritt-für-Schritt Angriffsablauf
Quellcode: Verwundbar vs. Sicher
Dies sind reduzierte, quellnahe Beispiele und kein wörtlicher Upstream-Diff. Der verwundbare Pfad behandelt den Clientnamen als Speicherpfad. Das gehärtete Muster validiert den Namen und prüft das kanonische Ziel relativ zur kanonischen Wurzel in der Speicherschicht; der Upstream-PR weist zusätzlich Trennzeichen und Steuerzeichen zurück und prüft die Begrenzung vor dem Anlegen von Verzeichnissen. Die Speicherprüfung bleibt auch dann nötig, wenn die HTTP-Schicht Eingaben validiert. Das Beispiel setzt eine Python-Version mit Path.is_relative_to voraus und verhindert für sich genommen keine TOCTOU-Rennen in für Angreifer beschreibbaren Verzeichnissen. Verwenden Sie in Produktion race-resistente Dateioperationen und restriktive Rechte. Die Abwehr ist Pfadbegrenzung, nicht nur eine Namens-Blacklist.[3], [2], [4], [7]
Quelltextauszug: Langflow api/v2/files.py und services/storage/local.py — reduziertes Beispiel der Sicherheitsgrenze
# Vereinfachtes Beispiel des verwundbaren Datenflusses.
new_filename = file.filename
file_path = folder_path / new_filename
await write_upload(file, file_path)
from pathlib import Path
def confined_upload_path(root: Path, client_name: str | None) -> Path:
name = Path(client_name or "").name
if not name or name in {".", ".."} or chr(0) in name:
raise ValueError("invalid upload filename")
base = root.resolve()
target = (base / name).resolve()
if not target.is_relative_to(base):
raise ValueError("upload path escapes storage root")
return target
# Unmittelbar vor dem Erstellen oder Schreiben an der Speichergrenze aufrufen.
target = confined_upload_path(upload_root, file.filename)
await write_upload(file, target)
Checkliste für Engineering & Systemsicherheit
- ✓Aktualisieren Sie Langflow auf 1.9.0 oder neuer und prüfen Sie die installierten langflow- und langflow-base-Versionen im Deployment-Image.[2], [4]
- ✓Validieren Sie Multipart-Namen getrennt von URL-Parametern; lehnen Sie Trennzeichen, Steuerzeichen, leere Namen und ungültige Kodierungen ab.[1], [2], [3]
- ✓Lösen Sie das Ziel kanonisch auf und erzwingen Sie die Begrenzung unter der Upload-Wurzel in der Speicherschicht vor Verzeichnisanlage und Schreibzugriff.[3], [4], [7]
- ✓Testen Sie Traversal, absolute Pfade, alternative Trennzeichen, Nullbytes, Unicode und Symlink-Ziele; außerhalb eines temporären Speichers darf keine Datei entstehen.[3], [7]
- ✓Betreiben Sie Langflow mit einem dedizierten Dienstkonto mit minimalen Rechten; halten Sie Uploads nicht ausführbar und getrennt von Code, geplanten Aufgaben und Zugangsdaten.[2], [4]
- ✓Prüfen Sie Internet-Exposition und Upload-Protokolle auf Namen außerhalb der Wurzel; untersuchen Sie den Vorfall und rotieren Sie Geheimnisse nur bei Hinweisen auf Hostzugriff.[6], [2]
- ✓Halten Sie die Zuordnung transparent: Tenable/GTIG verwenden
CVE-2026-5027; das zugehörige Langflow-GHSA nenntCVE-2026-33309. Schweregrad und Versionen nicht ungeprüft zusammenführen.[1], [2], [4], [5], [6]
Quellen
- CVE-Datensatz — CVE-2026-5027
- Tenable TRA-2026-26 — Path Traversal beim Langflow-Multipart-Upload
- Gemergter Langflow-PR #12227 — Namensvalidierung und Pfadbegrenzung
- Langflow GHSA-g2j9-7rj2-gm6c — zugehöriger Hinweis, CVE-2026-33309
- CVE-Datensatz — CVE-2026-33309
- Google GTIG — Trends bei Schwachstellen und Ausnutzung im KI-Zeitalter
- MITRE CWE-22 — unzureichende Begrenzung eines Pfads auf ein geschütztes Verzeichnis