Traversée de chemin dans Langflow : suppression de répertoires arbitraires du serveur

De quoi s’agit-il ?

Langflow est une plateforme open source très déployée pour construire des workflows LLM et agents, avec un large parc d’instances exposées sur Internet. Les mainteneurs ont publié un avis de sécurité (GHSA-9whx-c884-c68q) décrivant une traversée de chemin dans l’API des bases de connaissances qui autorise un utilisateur authentifié à supprimer des répertoires arbitraires sur le serveur. La faille touche Langflow 1.8.4 et les versions antérieures et est corrigée en 1.9.0. Elle est réapparue dans la veille sur les vulnérabilités en juillet 2026, au sein d’une vague plus large d’avis concernant Langflow et Ollama — un bon rappel que les instances exposées accusent souvent un retard important sur la version corrigée.

Cet article est une analyse défensive d’un problème divulgué et corrigé. Il ne reproduit aucun exploit fonctionnel : l’objectif est de comprendre la classe de faille et de savoir l’éviter dans son propre code.

Comment ça marche

La vulnérabilité se situe dans le gestionnaire de suppression en masse des bases de connaissances — l’endpoint DELETE /api/v1/knowledge_bases, implémenté par la fonction delete_knowledge_bases_bulk dans src/backend/base/langflow/api/v1/knowledge_bases.py.

La cause racine est un schéma classique de traversée de chemin (CWE-22). Le gestionnaire prend une liste de noms de bases de connaissances fournie par l’utilisateur et la concatène directement dans un chemin du système de fichiers, puis passe le résultat à une suppression récursive (shutil.rmtree()) — sans vérifier que le chemin résolu reste à l’intérieur du répertoire prévu pour l’utilisateur. Les autres endpoints passent par un utilitaire sûr (_resolve_kb_path()), mais la suppression en masse le contournait entièrement.

# Forme vulnérable (simplifiée, à titre d'illustration)
for name in kb_names:                 # contrôlé par l'attaquant
    target = base_dir / name          # aucune vérification de confinement
    shutil.rmtree(target)             # suppression récursive hors périmètre

# Un nom contenant une séquence de traversée « ../ » se résout
# EN DEHORS de base_dir : la suppression échappe au répertoire de l'utilisateur.

Comme un champ de nom peut porter une séquence de traversée ../, le chemin calculé sort du bac à sable et la suppression récursive atterrit là où pointe la séquence — y compris les données d’un autre locataire ou des chemins ailleurs sur l’hôte. Pas de corruption mémoire, pas d’exécution de code : juste une concaténation de chaînes qui alimente un appel de fichier destructeur.

Pourquoi c’est important

L’impact évalué porte sur l’intégrité et la disponibilité, pas sur la confidentialité — cela détruit des données plutôt que de les lire. L’avis classe la faille en critique (CVSS 9.6), avec un vecteur réseau, une faible complexité d’attaque et des privilèges seulement faibles requis (n’importe quel utilisateur authentifié).

Trois conséquences ressortent. D’abord, un rayon d’action inter-locataires : sur une instance multi-utilisateurs partagée, un compte authentifié peut effacer les répertoires de bases de connaissances d’un autre locataire. Ensuite, une interruption de service et une perte de données : la suppression peut retirer des fichiers applicatifs, des caches de modèles, de la configuration ou des sauvegardes colocalisées que le processus peut écrire, laissant potentiellement l’instance irrécupérable. Enfin, une exposition à grande échelle : les instances Langflow sont fréquemment accessibles depuis Internet, et beaucoup tournent derrière une authentification faible ou par défaut, si bien que le mot « authentifié » constitue une barrière plus basse qu’il n’y paraît.

Le schéma dépasse Langflow. Toute API qui laisse un client nommer une ressource puis fait correspondre ce nom au système de fichiers — pour des envois, des exports, des caches ou des suppressions — porte le même risque si elle fait confiance au nom.

Défenses

Le correctif et la leçon générale sont identiques : ne jamais faire confiance à un nom fourni par le client comme composant de chemin, et toujours confirmer que le chemin résolu reste à l’intérieur de sa racine autorisée.

• Passer à Langflow 1.9.0 ou une version ultérieure. C’est la remédiation directe. Le correctif (PR #12243) normalise le chemin fourni avec Path.resolve() et valide qu’il commence sous le répertoire de l’utilisateur authentifié avant toute suppression ; un suivi a renforcé la vérification avec Path.is_relative_to() pour éviter les bugs d’ambiguïté de préfixe.
• Imposer le confinement des chemins dans vos propres API de fichiers. Résolvez le chemin candidat et affirmez resolved.is_relative_to(base_dir) avant toute lecture, écriture ou suppression. Rejetez d’emblée les noms contenant des séparateurs ou des séquences de traversée plutôt que d’essayer de les nettoyer.
• Exécuter le processus avec le moindre privilège. Une traversée destructrice ne peut atteindre que ce que le compte de service peut écrire. Isolez les répertoires de données, retirez les droits d’écriture sur les chemins applicatifs et de sauvegarde, et gardez les sauvegardes hors du même système de fichiers.
• Ne pas exposer la surface admin/API à des réseaux non fiables. Placez Langflow derrière une authentification forte et une segmentation réseau ; traitez toute instance exposée sur Internet comme une priorité de correctif.
• Alerter sur les suppressions récursives et les signatures de traversée. Journalisez les appels de suppression de bases de connaissances et surveillez les séquences .. ou les séparateurs dans les paramètres de nom comme signal de détection.

Statut

Élément	Détail
Affecté	Langflow ≤ 1.8.4
Corrigé en	Langflow 1.9.0
Faiblesse	CWE-22 (traversée de chemin), impact intégrité/disponibilité
Sévérité	Critique, CVSS 9.6 (AV:N/AC:L/PR:L/UI:N/S:C/C:N/I:H/A:H)
Référence	CVE-2026-42048 · GHSA-9whx-c884-c68q
Divulgation	Avis publié le 27 avril 2026 ; couverture renouvelée en juillet 2026

Le correctif amont ne requiert aucun outillage propriétaire — passez à 1.9.0, appliquez le confinement des chemins dans tout endpoint de gestion de fichiers dont vous êtes responsable, et cadrez le compte de service pour qu’une traversée n’ait rien de précieux à détruire.