Une faille d’orchestration IA, pas un simple bug web
Langflow sert à construire des agents et des workflows d’IA, mais l’affaire en cours rappelle une évidence parfois oubliée: un outil d’IA est aussi une application web, une surface API, un coffre à secrets et, très souvent, un pont vers des services internes. La divulgation d’IBM couvre Langflow OSS de la version 1.0.0 à la version 1.12.8, avec Langflow 1.13.0 désignée comme version corrigée .
Les deux vulnérabilités principales sont CVE-2026-93680 et CVE-2026-110186, toutes deux notées 9,8 par IBM. La première relève d’une authentification incorrecte et peut permettre à un attaquant distant de contourner des restrictions de sécurité. La seconde concerne un contrôle insuffisant de la génération de code et peut permettre à un attaquant distant d’exécuter du code arbitraire sans compte utilisateur . En clair, le risque ne se limite pas à “voir l’interface”: il peut aller jusqu’à l’exécution côté serveur.
Le danger est amplifié par la nature même de Langflow. Une instance auto-hébergée peut contenir des clés de fournisseurs de modèles, des connecteurs vers des outils, des définitions de flows, des fichiers importés, des secrets d’API et parfois des accès à des services internes. Si cette couche d’orchestration est accessible depuis Internet ou depuis un réseau interne partagé, une faiblesse dans l’authentification et les limites d’exécution peut devenir un chemin direct vers la compromission de l’hôte.
Les versions touchées et le correctif
Le périmètre vulnérable est large: toutes les versions de Langflow OSS de 1.0.0 à 1.12.8 sont concernées par les failles critiques, tandis que la version 1.13.0 est la version corrigée mentionnée par les sources actuelles . The Hacker News a rapporté le 2 novembre que la version 1.12.8, publiée le même jour que la 1.13.0, restait vulnérable, et qu’aucune version de maintenance 1.12 ultérieure n’apparaissait sur PyPI au 2 novembre .
Le bulletin IBM inclut aussi deux failles supplémentaires. CVE-2026-110193, notée 8,8, nécessite un compte à faibles privilèges et peut permettre de pousser l’Agentic Assistant à générer ou soumettre du code de composant exécutant des commandes du système d’exploitation. CVE-2026-110192, notée 6,5, concerne une protection insuffisante des identifiants et peut exposer des informations sensibles à un attaquant authentifié .
Ce mélange est important. Les vulnérabilités sans authentification créent l’urgence immédiate, mais les failles authentifiées révèlent un problème plus structurel: dans un environnement de workflows IA, la frontière entre modifier un flow, invoquer un outil et exécuter du code serveur peut devenir trop mince.
Le chemin MCP rend l’incident plus grave
Une analyse récente décrit une chaîne d’attaque particulièrement directe: les versions 1.0.0 à 1.12.8 de Langflow peuvent exposer un comportement d’auto-login, dans lequel une requête non authentifiée vers l’endpoint d’auto-connexion peut retourner une session superutilisateur lorsque la configuration vulnérable par défaut est en place . À partir de cette position, l’attaquant peut atteindre la surface Model Context Protocol de Langflow, énumérer les outils de création et d’exécution de flows, puis progresser vers une exécution de code distante non authentifiée via CVE-2026-110186 .
C’est précisément ce qui rend l’expression “faille d’outil IA” trop faible. La découverte d’outils MCP et l’exécution de workflows sont des fonctions normales de la plateforme. Elles servent à permettre aux agents de trouver et d’utiliser des outils. Mais si l’authentification échoue, ces fonctions deviennent des primitives d’attaque. Les éléments qui rendent une plateforme agentique utile — énumération d’outils, composition de composants, hooks d’exécution — peuvent devenir un itinéraire assisté vers le runtime.
La même analyse indique que Langflow 1.13.0 désactive l’auto-login et qu’aucun contournement n’est proposé pour la branche vulnérable . Elle souligne aussi un piège opérationnel: les administrateurs qui dépendaient de l’auto-login doivent préparer un accès par mot de passe avant la mise à niveau, faute de quoi la désactivation de l’auto-login peut aussi les exclure de leur propre instance .
Pas d’exploitation confirmée, mais aucune raison d’attendre
Selon les sources actuelles, ces CVE spécifiques ne figuraient pas dans le catalogue Known Exploited Vulnerabilities de la CISA, et aucune exploitation n’était rapportée pour les nouvelles failles discutées . Ce point ne doit pas être interprété comme un signal de faible priorité. Le même article note que d’autres failles Langflow sont déjà apparues dans le catalogue de la CISA, et la plateforme a déjà suscité l’intérêt d’attaquants lors de vagues précédentes .
Un récapitulatif du 2 novembre consacré aux vulnérabilités IA listait encore CVE-2026-93680 parmi les failles récentes touchant des outils d’IA, avec la plage affectée 1.0.0 à 1.12.8 et une sévérité critique de 9,8 . Ce classement illustre une évolution importante: les équipes de sécurité traitent désormais l’infrastructure de développement IA comme une surface d’attaque à part entière. Les constructeurs d’agents, serveurs MCP, passerelles de modèles et plateformes de workflows ne sont plus des systèmes expérimentaux isolés; ils se rapprochent des secrets et de l’automatisation métier.
La conclusion n’est pas que Langflow serait exceptionnellement dangereux. La conclusion est que l’infrastructure IA adoptée rapidement hérite des risques classiques des applications web tout en augmentant le rayon d’impact. Un panneau d’administration traditionnel peut exposer une configuration. Un serveur d’orchestration IA peut exposer une configuration, des secrets, des composants exécutables, des outils, des prompts, des connecteurs de données et des comptes de modèles.
Ce que les opérateurs doivent faire
La première étape est l’inventaire. Les équipes doivent identifier toutes les installations de Langflow: machines de développeurs, conteneurs Docker, laboratoires, environnements de préproduction et instances internes “temporaires”. Si la version se situe entre 1.0.0 et 1.12.8, elle doit entrer dans la file de correction urgente .
La deuxième étape est la préparation de la mise à niveau. Les sources actuelles pointent vers Langflow 1.13.0, avec sauvegarde préalable de la base de données, de la clé secrète et des fichiers importés . Les utilisateurs du paquet Python doivent passer au paquet corrigé, et les utilisateurs Docker au conteneur corrigé, en conservant les données persistantes .
La troisième étape est la validation des accès. Si une instance dépendait auparavant de l’auto-login, les administrateurs doivent préparer un véritable accès par mot de passe avant l’upgrade, puis vérifier que l’auto-login n’est plus disponible après la migration . Ils doivent aussi s’assurer que l’endpoint MCP et les surfaces d’exécution de flows ne sont pas accessibles aux utilisateurs non authentifiés ni à des segments réseau qui n’en ont pas besoin.
La quatrième étape concerne les identifiants. Comme Langflow peut stocker des clés de fournisseurs de modèles, des tokens API, des secrets de webhooks, des identifiants de bases de données et d’autres éléments opérationnels, appliquer le patch ne suffit pas toujours. Si un serveur vulnérable était exposé avant correction, il est prudent de faire tourner les clés stockées et d’examiner l’historique des flows, les fichiers importés, les logs et les comptes récemment créés.
La leçon de sécurité IA
Les dernières failles Langflow montrent où doit se déplacer une partie du travail de sécurité IA. La sûreté des prompts et le comportement des modèles restent importants, mais le runtime autour du modèle est désormais tout aussi critique. Authentification, autorisation, gestion des secrets, exposition des outils, dépendances et contrôles d’exécution de code ne sont pas de simples détails d’infrastructure: ils forment la frontière de sécurité des systèmes agentiques.
Le low-code ne signifie pas low-risk. Ici, un constructeur visuel de workflows peut concentrer les clés, les outils et les chemins d’exécution qui donnent de la valeur à une pile IA. Lorsqu’il est exposé, la réponse à incident ne se résume pas à corriger une interface. Il faut vérifier qui pouvait se connecter, quels outils pouvaient être énumérés, quel code pouvait s’exécuter et quels secrets doivent peut-être déjà être remplacés.
Pour les équipes qui utilisent Langflow, le résumé opérationnel est simple: trouver les instances, passer à la version 1.13.0, réduire l’exposition réseau, valider l’authentification et traiter tout serveur vulnérable publiquement accessible comme un possible événement de compromission d’identifiants. Le workflow est peut-être low-code, mais la réponse à incident est clairement en mode cauchemar.
Commentaires
Sois le premier à commenter.