FlawOpen

flawopen.com/Teardowns/cve-2026-5027-langflow-multipart-file-write

● CVE-2026-5027 · CVSS 8.8[1], [2] · Hoch
Sicherheitsforschung · FlawOpen

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]

CVSS-VektorCVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H[1], [2]
💡 Einfache Erklärung (ELI5)

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]
Pfadbegrenzung
Eine Prüfung, die den Zielpfad kanonisch auflöst und vor dem Anlegen oder Schreiben nachweist, dass er unter dem freigegebenen Speicherordner bleibt.[3], [4], [7]
Hinweis zu Kennungen
Langflows zugehöriges GHSA nennt CVE-2026-33309, Tenable und Google GTIG dagegen CVE-2026-5027. Dieser Artikel folgt der GTIG-Kennung und führt beide Datensätze auf, ohne ihre Metadaten stillschweigend zusammenzuführen.[4], [5], [6]

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

Schritt 1

Ein Nutzer mit geringen Rechten erreicht den Upload-Endpunkt

Der CVSS-Vektor von CVE-2026-5027 verlangt geringe Rechte. Betroffen ist POST /api/v2/files; der Datensatz belegt keinen Authentifizierungs-Bypass.[1], [2]

Schritt 2

Die Anfrage liefert einen Multipart-Dateinamen

Der Name stammt aus clientgesteuerten Content-Disposition-Metadaten. URL-Parameter-Prüfungen bereinigen diese separate Eingabe nicht.[1], [2], [4]

Schritt 3

Der Pfad überschreitet die Speichergrenze

Ohne kanonische Pfadprüfung können Traversal-Komponenten außerhalb des Upload-Ordners aufgelöst werden.[1], [2], [3], [7]

Schritt 4

Eine Datei landet außerhalb der Wurzel

Dokumentiert ist beliebiges Schreiben. Codeausführung hängt von beschreibbaren Pfaden, Prozessrechten und Bereitstellung ab; nicht jeder Upload führt zu RCE.[1], [2], [6]

Schritt 5

Beide Prüfgrenzen absichern

Langflow hat API-Namensprüfung und kanonische Speicherbegrenzung in die 1.9.0-Linie übernommen. Aktualisieren Sie und prüfen Sie installierte Pakete sowie das laufende Image.[2], [3], [4]

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

VERWUNDBARE IMPLEMENTIERUNG
# Vereinfachtes Beispiel des verwundbaren Datenflusses.
new_filename = file.filename
file_path = folder_path / new_filename
await write_upload(file, file_path)
GEHÄRTETER SICHERHEITS-PATCH
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

Quellen