Détournement de flux inter-tenant dans Langflow via un contrôle d'autorisation défaillant

What is this?

Langflow est un framework visuel open source très déployé pour construire des agents LLM et des pipelines de génération augmentée par la récupération (RAG). Le 19 juin 2026, ses mainteneurs ont publié un avis de sécurité concernant une référence directe d’objet non sécurisée (IDOR) dans l’endpoint /api/v1/responses : tout utilisateur authentifié pouvait exécuter un flux appartenant à un autre utilisateur en indiquant simplement l’identifiant de ce flux dans la requête. L’endpoint acceptait un identifiant de flux fourni par le client mais ne vérifiait jamais que l’appelant en était bien le propriétaire.

La faille est sérieuse parce que les flux Langflow embarquent couramment des secrets vivants — clés de fournisseurs LLM, identifiants cloud, chaînes de connexion à des bases — directement dans la configuration de leurs composants. Détourner le flux d’autrui n’est donc pas seulement une exécution non autorisée : c’est un chemin vers ses identifiants. L’équipe Threat Research de Sysdig a signalé la première exploitation observée dans la nature le 25 juin 2026, et la CISA américaine a ajouté la vulnérabilité à son catalogue Known Exploited Vulnerabilities le 7 juillet 2026, avec une échéance de remédiation au 10 juillet pour les agences fédérales civiles. Le correctif était déjà disponible, dans Langflow 1.9.1.

How it works

La cause racine est un unique contrôle de propriété manquant dans la fonction d’aide get_flow_by_id_or_endpoint_name (helpers/flow.py). Lorsqu’un flux est recherché par endpoint_name lisible, la requête est restreinte à l’utilisateur courant. Lorsque le même flux est recherché par UUID, elle ne l’est pas :

# Illustratif — la branche vulnérable résolvait un flux par UUID
# sans confirmer que le demandeur en était propriétaire.
flow_id = UUID(flow_id_or_name)
flow = await session.get(Flow, flow_id)   # aucun contrôle de propriétaire ici
# ...
# La branche endpoint_name, elle, filtrait bien sur user_id.

L’endpoint /api/v1/responses est compatible OpenAI-Responses : il traite le champ model comme un UUID de flux. Fournissez-lui l’UUID d’un autre tenant et la plateforme exécute le flux de ce tenant — sous les identifiants embarqués de ce tenant — via son propre chemin d’exécution légitime.

Il existe une contrainte honnête, et il faut la dire clairement : un UUID de flux Langflow est une valeur aléatoire de 122 bits. Il ne peut pas être deviné par force brute, et le chemin endpoint_name est correctement restreint : il n’y a donc pas de raccourci par devinette de slug. L’exploitation dépend d’abord obtenir un identifiant de flux valide. Dans l’intrusion observée, l’opérateur a récupéré la liste GET /api/v1/flows/ — qui divulguait les identifiants — puis a rejoué ces identifiants sur l’endpoint responses. C’est le chaînage classique divulgation vers IDOR : un endpoint de listing trop permissif est ce qui transforme une référence d’objet « indevinable » en attaque opérante.

Exemple de prompt

L’extrait ci-dessous illustre la technique de façon défensive : l’endpoint responses traitait le champ model comme un UUID de flux et l’exécutait sans contrôle de propriété, si bien qu’un identifiant de flux divulgué pouvait exécuter le flux d’un autre tenant sous ses identifiants embarqués. Aucun exploit fonctionnel n’est montré — c’est pour les défenseurs.

# Langflow cross-tenant flow hijack (illustrative, defensive)
# The /api/v1/responses endpoint treats "model" as a flow UUID and
# ran it WITHOUT checking the caller owned it (pre-1.9.1):
victim_flow_id = "[REDACTED-flow-uuid]"   # first leaked via GET /api/v1/flows/
POST /api/v1/responses  { "model": victim_flow_id, "input": "[hidden instruction]" }
# -> runs another tenant's flow under THEIR embedded API keys.
# Root cause: missing ownership check on the UUID lookup path (IDOR).
# Defense: upgrade to Langflow 1.9.1+, scope object lookups to the caller,
# authorize/rate-limit ID-listing endpoints, and vault your secrets.

Why it matters

L’enseignement de ce cas est que le score CVSS n’est pas un classement d’exploitabilité. La faille d’autorisation de flux obtient un 9.9 parce qu’elle brise le périmètre inter-tenant, pourtant Sysdig a vu le même opérateur la traiter comme une réflexion de dernière minute en deux requêtes, tout en concentrant ses efforts sur une faille d’exécution de code à distance distincte et non authentifiée dans le même produit (scorée plus bas, à 9.3, mais projetable en masse sur Internet et sans identifiants). Sur une seule instance auto-hébergée, l’exécution de code est un sur-ensemble strict de ce que rapporte l’IDOR : les attaquants qui optimisent l’effort par rapport au gain se tournent donc vers le RCE.

L’IDOR mérite sa gravité dans un cadre précis : Langflow multi-tenant ou managé. Là, les flux des tenants s’exécutent dans des workers isolés, si bien que le RCE est confiné par tenant et ne peut, à lui seul, franchir la frontière. La faille d’autorisation, elle, le peut — discrètement, au niveau applicatif, sous la forme d’un appel d’API d’apparence légitime dont la seule anomalie est le mauvais identifiant de flux. Pour quiconque opère Langflow en service partagé, c’est le chemin qui atteint les secrets d’un autre client, et il reste bien en dessous de l’empreinte de détection du RCE bruyant.

La leçon plus large dépasse ce seul produit. Les plateformes d’orchestration d’IA concentrent des identifiants par conception, ce qui en fait des cibles de grande valeur, et leurs bases de code à évolution rapide continuent de livrer des bugs d’autorisation web classiques. Traitez ces plateformes avec la même rigueur de contrôle d’accès que n’importe quel SaaS multi-tenant.

Defenses

1. Corrigez et vérifiez la version. Le correctif est arrivé dans Langflow 1.9.1 (PR #12832) ; utilisez la dernière version. La propriété est désormais vérifiée sur les deux branches de recherche, et les recherches inter-utilisateurs renvoient un 404 plutôt qu’un 403 pour éviter un oracle d’existence.
2. Traitez les endpoints de divulgation d’identifiants comme partie de la surface d’attaque de l’IDOR. La route de listing qui fuitait les UUID de flux est ce qui rendait la faille atteignable. Les endpoints d’énumération d’objets méritent la même revue d’autorisation et le même throttling que les actions sensibles qu’ils déverrouillent.
3. Cessez d’embarquer des secrets en clair dans les flux. Référencez les identifiants via un gestionnaire de secrets ou un magasin de variables de la plateforme, plutôt que de coller des clés de fournisseurs et de cloud dans la configuration des composants. Si un flux a été exposé, faites tourner chaque clé qu’il portait — supposez la compromission.
4. N’exposez pas d’instances auto-hébergées sans authentification. L’opérateur observé sondait d’abord le défaut auto_login sans authentification. Placez Langflow derrière une authentification et des contrôles réseau ; ne publiez jamais une instance dotée de capacités d’administration sur Internet ouvert.
5. Imposez l’isolation au niveau applicatif pour les déploiements multi-tenant. Le sandboxing par worker et par tenant n’arrête pas une rupture d’autorisation applicative. Restreignez chaque recherche d’objet à l’appelant et testez explicitement le cas inter-tenant.
6. Surveillez la chaîne, pas seulement le payload. Un appel d’énumération (/api/v1/flows/) immédiatement suivi d’appels /api/v1/responses portant des identifiants fraîchement listés est un signal fort. Sysdig et SentinelOne ont publié des indicateurs de compromission pour la campagne observée.

Status

Élément	Référence	Date	Notes
Avis éditeur (IDOR, CWE-639)	GHSA-qrpv-q767-xqq2 / CVE-2026-55255	2026-06-19	CVSS 9.9, périmètre modifié ; affecte < 1.9.1
Correctif publié	Langflow 1.9.1 (PR #12832)	2026-04-22 (merge)	Propriété vérifiée sur les deux chemins
Première exploitation dans la nature	Sysdig TRT	2026-06-25	Chaîne énumération → responses ; prompt « leak api keys »
Ajout au CISA KEV	Alerte CISA	2026-07-07	Échéance fédérale de remédiation 2026-07-10
RCE chaîné (même produit)	CVE-2026-33017	KEV 2026-03-25	Non authentifié, CVSS 9.3, exploité en masse en ~20 h

La divulgation responsable a été respectée : les rapporteurs ont été crédités et un correctif a été publié avant l’avis public. Le bon enseignement n’est pas « encore un CVE d’IA » mais un rappel : les bugs classiques d’autorisation défaillante atterrissent désormais dans les outils qui détiennent vos clés de modèle et de cloud — et qu’un score CVSS élevé renseigne sur l’impact, pas sur la faille qu’un attaquant atteindra réellement en premier.