Langflow : quand un contrôle de code et une connexion automatique ne tiennent plus

Bulletin IBM du 28 octobre 2026. IBM recense plusieurs failles dans Langflow OSS jusqu’à la branche 1.12.8, dont CVE-2026-93680, contournement de l’authentification, et CVE-2026-110186, injection de code pouvant donner une RCE distante. Le cas est intéressant car Langflow est conçu pour assembler des composants et des outils d’agent : la frontière entre « configurer un flux » et « exécuter du Python sur le serveur » y est déjà mince. La sécurité dépend de l’identité de celui qui peut créer le composant et de la solidité du contrôle appliqué avant son importation.

Deux barrières qui ne doivent pas être confondues

L’authentification répond à « qui soumet la demande ? ». Le contrôle de code répond à « quels effets cette demande peut-elle produire ? ». Une faiblesse dans l’une ne prouve pas automatiquement une RCE, mais leur combinaison peut exposer la seconde à un acteur qui n’aurait jamais dû atteindre l’interface. Le bulletin IBM décrit CVE-2026-93680 comme un défaut d’authentification et CVE-2026-110186 comme une exécution de code due à un contrôle insuffisant de la génération de code. Il mentionne aussi l’exposition d’une voie de RCE par l’énumération d’outils MCP. Ces descriptions sont des conclusions de l’éditeur ; elles ne détaillent pas dans le bulletin chaque requête ni chaque fonction appelée.

Un PoC publié par un chercheur documente une chaîne précise dans des versions qu’il a testées : avec LANGFLOW_AUTO_LOGIN=true, l’endpoint auto_login pouvait remettre un jeton de superutilisateur à un appelant non authentifié ; le chercheur soumettait ensuite un composant Python au mécanisme de validation, puis montrait son exécution. Il identifie ce chemin d’authentification et le défaut du scanner de code comme deux maillons. Son périmètre de test, 1.9.0 à 1.12.5, est plus étroit que le périmètre de mise à jour annoncé par IBM ; on ne doit pas substituer les bornes d’un PoC aux versions que l’éditeur demande de corriger.

Pourquoi une liste de modules interdits échoue

Le scanner analysait l’arbre syntaxique du composant pour refuser des imports ou accès jugés dangereux, notamment os, subprocess et ctypes. Le chercheur montre qu’un module apparemment permis, pydoc, réexporte os. Le code soumis peut donc accéder à une capacité interdite par un autre chemin d’attributs sans écrire l’import que la liste noire attend. Il signale également une variante par numpy.ctypeslib. Le défaut n’est pas qu’un modèle d’IA « comprend mal » une consigne : c’est une limite classique de l’analyse statique par noms interdits dans un langage où les objets et modules sont composables.

Le chemin d’exécution décrit par le PoC passe par l’enregistrement d’un composant, sa validation, son écriture dans le répertoire des composants, puis son importation comme module Python. Une fois l’importation atteinte, le scanner est la dernière barrière applicative visible dans cette route. Le PoC contient une capture réseau et des tests comparant version vulnérable et version corrigée ; cela apporte une preuve plus forte qu’un simple exemple de code qui « devrait marcher ». Nous ne déduisons toutefois pas de ce PoC que tous les déploiements exposent auto_login, ni que la route MCP mentionnée par IBM fonctionne de la même façon. Configuration, exposition réseau et version restent déterminantes.

Comment rechercher la classe de faille

Un audit autorisé commence par inventorier toutes les routes menant à l’enregistrement d’un composant et à l’exécution de code, y compris les fonctions d’agent et les outils MCP. Il vérifie ensuite les droits demandés par chaque route avec une session absente, faible et administrateur. Pour le scanner, il faut suivre les objets réellement accessibles à l’exécution et comparer la politique prévue avec les capacités que des bibliothèques permises réexportent. Le test différentiel sur une version corrigée permet de vérifier la fermeture des voies démontrées.

La découverte effective de CVE-2026-110186 est décrite dans le dépôt du chercheur ; l’analyse ci-dessus suit ce PoC, mais le bulletin IBM regroupe plusieurs vulnérabilités et n’attribue pas tous leurs chemins à ce seul travail. C’est une raison supplémentaire de citer le PoC près des détails qu’il établit, sans attribuer à la même chaîne toutes les conclusions du bulletin.

Mesurer l’impact et corriger

Un serveur Langflow compromis peut exposer les secrets qu’il utilise pour connecter modèles, fournisseurs et systèmes internes. C’est une conséquence plausible de l’exécution de code avec les droits du service, pas une preuve qu’une telle exfiltration a eu lieu sur une installation donnée. Le bulletin IBM recommande Langflow OSS 1.13.0 pour les versions 1.0.0 à 1.12.8 et ne propose pas de contournement général. L’inventaire doit relever la version exécutée, l’exposition de l’interface, la configuration d’auto-login, les composants créés et les secrets accessibles au processus. Une mise à jour corrige les voies connues ; elle ne remplace pas la revue des composants et des identifiants si un serveur était accessible avant correction.

La leçon technique est double : une politique de code fondée sur des noms bannis ne représente pas les capacités réellement atteignables, et une connexion automatique pensée pour simplifier le démarrage peut rendre publique une surface qui exécute du code. Les deux frontières doivent être testées séparément et ensemble.

Sources principales : bulletin IBM, PoC et analyse du chercheur pour CVE-2026-110186, notes de version Langflow 1.13.0.