Détournement de flow inter-tenant dans Langflow : le 9.9 que les attaquants ont ignoré

De quoi s’agit-il ?

Le 26 juin 2026, la Threat Research Team de Sysdig a publié la première exploitation documentée d’une faille inter-tenant dans Langflow, le framework visuel open source de construction d’agents IA et de pipelines RAG. La faille est une référence directe à un objet non sécurisée (IDOR) inter-tenant : un utilisateur authentifié peut exécuter le flow d’un autre utilisateur — et hériter des secrets qui y sont embarqués. Elle porte un score CVSS de 9.9, supérieur à la faille d’exécution de code à distance non authentifiée exploitée à ses côtés, notée 9.3.

Le plus instructif est ce que l’attaquant n’a pas fait. Sysdig a observé un seul opérateur, le 25 juin 2026, lancer les deux failles contre la même instance exposée. Il a concentré ses efforts sur le RCE moins bien noté et traité la faille inter-tenant, pourtant mieux notée, comme un à-côté de deux requêtes. C’est un article de fond sur une classe de vulnérabilité et une leçon de lecture des scores CVSS, pas un exploit actionnable — les deux failles sont corrigées.

Comment ça marche

Langflow expose chaque flow comme un « modèle » appelable via un endpoint compatible OpenAI. Une requête vers POST /api/v1/responses désigne un flow par son UUID dans le champ model. La faille se trouvait dans l’assistant de résolution de flow : lorsqu’un flow était résolu par UUID, la requête en base s’exécutait sans vérification de propriété, si bien que n’importe quel appelant authentifié pouvait exécuter le flow de n’importe quel utilisateur. Le chemin parallèle qui résout un flow par son nom d’endpoint, lui, vérifiait la propriété — seule la branche UUID était exposée.

Étape       Ce qu'a fait l'opérateur
----------  ---------------------------------------------------
Énumérer    GET /api/v1/flows/  — un endpoint de liste qui
            divulgue les UUID de flows d'autres utilisateurs.
Détourner   POST /api/v1/responses  avec model:<flow-victime>
            et un prompt injecté en input, ex. « [REDACTED :
            instruction de récupération d'identifiants] ».
Récolter    Le flow de la victime s'exécute avec ses clés
            embarquées ; le prompt injecté les fait ressortir.

Un UUID de flow est aléatoire et large de 122 bits : impossible à brute-forcer. C’est toute l’histoire de cette faille : seule, elle est inerte. Elle ne devient exploitable que parce que l’endpoint de liste distribue précisément les identifiants dont l’attaque a besoin. Le correctif, livré dans Langflow 1.9.1, ajoute la vérification de propriété manquante au chemin UUID.

Pourquoi c’est important

Sur une machine auto-hébergée unique, cette faille inter-tenant ne fait rien que le RCE voisin ne puisse déjà faire — dès qu’on obtient une exécution de code non authentifiée, on possède le processus, la base, le système de fichiers et l’environnement. Cette asymétrie explique pourquoi le RCE a été massivement exploité en 20 heures après sa divulgation de mars, a touché environ 7 000 serveurs exposés et figure au catalogue des vulnérabilités activement exploitées (KEV) de la CISA, tandis que la faille inter-tenant, mieux notée, n’avait jusqu’ici aucune exploitation signalée. Les attaquants optimisent le rendement par unité d’effort, et un RCE non authentifié et pulvérisable sur tout Internet gagne à chaque fois.

L’exception, c’est le Langflow multi-tenant ou managé. Là, le RCE s’exécute dans un bac à sable par tenant — atteindre un autre client exige une évasion de sandbox. La faille inter-tenant, elle, franchit cette frontière au niveau applicatif, via le chemin d’exécution béni de la plateforme, en exécutant le flow de la victime avec ses identifiants. Aucune compromission de l’hôte, aucune évasion, et cela ressemble à un appel d’API légitime dont la seule anomalie est un « mauvais » identifiant de flow. Elle est donc à la fois plus impactante et plus discrète précisément là où le RCE est contenu. Et les flows Langflow valent la peine d’être ciblés : ils embarquent couramment des clés de fournisseurs LLM, des identifiants cloud et des secrets de base directement dans la configuration des composants.

Défenses

Rien ici ne réclame de contrôle inédit — il faut corriger et traiter l’autorisation comme une propriété de la couche données, pas du réseau.

1. Passez à Langflow 1.9.1 ou plus récent, qui ajoute la vérification de propriété. Corrigez le RCE non authentifié dans la foulée — c’est lui qui est pulvérisé à l’échelle d’Internet.
2. Traitez les endpoints qui divulguent des identifiants d’objets comme faisant partie de la surface d’attaque. La faille inter-tenant est inerte sans UUID de flow fuité ; l’endpoint de liste trop bavard est ce qui l’arme. Restreignez les listes aux objets de l’appelant.
3. N’exposez pas Langflow à Internet, et désactivez tout défaut sans authentification ou auto-login. Placez-le derrière des contrôles réseau authentifiés.
4. Opérateurs multi-tenant : appliquez l’autorisation à la couche données, pas seulement via l’isolation par sandbox. Donnez au correctif applicatif l’urgence qu’implique le score 9.9 — le bac à sable n’arrête pas une rupture de tenant applicative.
5. Cessez d’embarquer des secrets à longue durée de vie dans les configurations de flows. Utilisez des identifiants courts et à portée limitée issus d’un gestionnaire de secrets, et faites tourner toute clé ayant résidé sur une instance exposée.
6. Ajoutez une détection à l’exécution de l’énumération de flows suivie d’une exécution inter-propriétaire, et des prompts dont l’intention est de faire ressortir des identifiants.

Status

Élément	Référence	Date	Notes
Détournement de flow inter-tenant	CVE-2026-55255	2026	IDOR CVSS 9.9 ; corrigé dans Langflow 1.9.1
Première exploitation réelle	Sysdig TRT	2026-06-25	Énumération → détournement, 2 requêtes ; aucune exploitation antérieure
RCE non authentifié voisin	CVE-2026-33017	2026-03	CVSS 9.3 ; CISA KEV 2026-03-25 ; ~7 000 serveurs touchés
Recherche publique	Sysdig TRT	2026-06-26	Analyse comparée de l’effort sur les deux failles

Ce qu’il faut retenir n’est pas qu’un score CVSS élevé serait faux — c’est qu’un score mesure l’impact dans le pire des cas, pas l’exploitabilité. Un 9.9 qui exige une authentification, un identifiant d’objet fuité et une cible multi-tenant perd, en pratique, face à un 9.3 accessible avec pour seul prérequis un accès réseau. Corrigez les deux, mais lisez le score pour ce qu’il est.