flawopen.com/Teardowns/cve-2026-5027-langflow-multipart-file-write
Langflow CVE-2026-5027 : traversal dans les fichiers multipart
CVE-2026-5027 permettait d’écrire hors du dossier d’envoi de Langflow par traversal. GTIG signale une exploitation ; passez à 1.9.0+.[1], [2], [6]
Un centre de courrier accepte un colis dont l’expéditeur choisit l’étiquette et la destination. Si l’employé assemble cette étiquette au dossier sans vérifier le chemin final, le colis peut sortir du centre. La route d’envoi de Langflow faisait confiance au nom multipart, tandis que le stockage ne vérifiait pas séparément que le chemin restait dans le dossier autorisé.[2], [3]
Concepts Clés et Termes
CVE-2026-5027- Identifiant attribué par Tenable à un path traversal dans le nom multipart de POST /api/v2/files de Langflow :
CWE-22, CVSS 3.1 8,8 et privilèges faibles requis.[1], [2] Nom multipart- Nom fourni par le client dans Content-Disposition d’un envoi multipart. C’est une entrée non fiable, pas un chemin de fichier sûr.[1], [2]
Correspondances de référentiels
- Référence CWE pour la faiblesse décrite dans ce guide : CWE-22
Analyse de Cause Racine
La fiche CVE-2026-5027 de Tenable décrit POST /api/v2/files acceptant un nom multipart contenant des éléments de traversal et écrivant hors du dossier prévu. La frontière de sécurité comprend la route API et le stockage local : valider des paramètres d’URL ne valide pas un nom issu de Content-Disposition, et joindre ce nom au dossier ne prouve pas le confinement. Le vecteur CVE exige des privilèges faibles (PR:L) ; n’affirmez pas que la CVE contourne l’authentification. Google GTIG inclut CVE-2026-5027 parmi les vulnérabilités exploitées dans la nature, mais son résumé public n’établit pas une exécution de code universelle. L’écriture arbitraire peut avoir des conséquences plus graves selon les chemins accessibles en écriture, les privilèges du processus et la configuration ; présentez-les comme conditionnelles, pas comme un RCE garanti. Le GHSA associé de Langflow indique CVE-2026-33309 et renvoie aussi au correctif 1.9.0. Cet article suit CVE-2026-5027, comme Tenable et GTIG, et explicite l’écart d’identifiants. La PR fusionnée valide les noms côté API et applique le confinement canonique côté stockage, avant même la création des dossiers.[1], [2], [3], [4], [5], [6]
Déroulement de l'Attaque Étape par Étape
Code Source : Vulnérable vs Sécurisé
Ces extraits réduits reprennent la forme du code, sans être un diff littéral de l’amont. Le chemin vulnérable traite le nom client comme chemin de stockage. Le modèle corrigé valide le nom puis vérifie la destination canonique par rapport à la racine canonique dans la couche de stockage ; la PR amont rejette aussi les séparateurs et caractères de contrôle et vérifie le confinement avant de créer les dossiers. Gardez ce contrôle côté stockage même si la couche HTTP valide l’entrée. L’exemple requiert une version de Python prenant en charge Path.is_relative_to et ne supprime pas à lui seul les courses entre vérification et utilisation dans un dossier accessible à un attaquant. En production, utilisez des opérations de fichiers résistantes aux courses et des permissions restrictives. La défense est le confinement du chemin, pas une simple liste noire de noms.[3], [2], [4], [7]
Extrait source: Langflow api/v2/files.py et services/storage/local.py — exemple réduit de la frontière de sécurité
# Exemple réduit du flux de données vulnérable.
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
# Appelez ceci à la frontière de stockage, juste avant la création ou l’écriture.
target = confined_upload_path(upload_root, file.filename)
await write_upload(file, target)
Liste de Contrôle de Sécurité pour l'Ingénierie
- ✓Passez à Langflow 1.9.0 ou ultérieur et vérifiez les versions de langflow et langflow-base dans l’image déployée.[2], [4]
- ✓Validez les noms multipart séparément des paramètres d’URL ; rejetez séparateurs, caractères de contrôle, noms vides et encodages invalides.[1], [2], [3]
- ✓Résolvez la destination et imposez le confinement canonique sous la racine d’envoi dans le stockage, avant toute création de dossier et écriture.[3], [4], [7]
- ✓Testez traversal, chemins absolus, séparateurs alternatifs, octets nuls, Unicode et destination symbolique ; vérifiez qu’aucun fichier ne sort d’une racine temporaire.[3], [7]
- ✓Exécutez Langflow avec un compte de service dédié à privilèges minimaux et séparez les envois non exécutables du code, des tâches planifiées et des identifiants.[2], [4]
- ✓Examinez l’exposition Internet et les journaux d’envoi ; enquêtez sur les noms hors racine et ne faites tourner les secrets qu’en présence d’indices d’accès à l’hôte.[6], [2]
- ✓Gardez la correspondance explicite : Tenable/GTIG utilisent
CVE-2026-5027; le GHSA associé de Langflow indiqueCVE-2026-33309. Ne fusionnez pas gravité ou versions sans vérifier les fiches.[1], [2], [4], [5], [6]
Sources
- Fiche CVE — CVE-2026-5027
- Tenable TRA-2026-26 — traversal d’envoi multipart Langflow
- PR Langflow fusionnée #12227 — validation des noms et confinement
- Langflow GHSA-g2j9-7rj2-gm6c — avis associé, CVE-2026-33309
- Fiche CVE — CVE-2026-33309
- Google GTIG — tendances de découverte et d’exploitation à l’ère de l’IA
- MITRE CWE-22 — limitation incorrecte d’un chemin à un répertoire restreint