CVE-2026-9198 : RCE non authentifiée sur les plans de contrôle d'agents IBM Langflow OSS

Les versions open source 1.0.0 à 1.10.0 d'IBM Langflow contiennent un enchaînement d'exécution de code à distance scoré CVSS 9,8 sous CVE-2026-9198. La faille n'est pas un bug logique subtil dans un modèle de prompt. C'est une rupture de frontière d'authentification sur un plan de contrôle joignable depuis Internet : /api/v1/auto_login remet un jeton SUPERUSER à tout appelant, et /api/v1/validate/code exécute du Python fourni par l'attaquant via exec().

Langflow appartient à une catégorie de logiciels entrés discrètement dans les registres de risque de périphérie. Les équipes le déploient pour assembler des workflows LLM, des connecteurs d'outils et des graphes d'agents. Cela ressemble à de l'infrastructure développeur. Sur le plan opérationnel, cela se comporte comme une console d'administration à distance avec accès à chaque clé API stockée dans le projet — parce que c'est ce qu'est un plan de contrôle d'agents.

IBM a corrigé le problème dans Langflow 1.10.1. Les administrateurs doivent aussi définir LANGFLOW_AUTO_LOGIN=false sur tout déploiement qui n'exige pas explicitement cette fonctionnalité. La CISA a ajouté CVE-2026-9198 au catalogue KEV le 4 août 2026, avec une échéance fédérale de remédiation au 7 août en vertu de la BOD 26-04. Un proof of concept est suivi environ une semaine après la divulgation. Si votre instance Langflow était sur Internet fin juillet et début août, la question n'est plus de savoir s'il faut corriger — c'est de savoir si quelqu'un a déjà parcouru la chaîne.

Comment la chaîne contourne l'authentification

Langflow expose une API REST pour construire et exécuter des flows. Deux points de terminaison composent le chemin d'exploitation observé :

• /api/v1/auto_login — Conçu comme commodité de développement, cette route émet une session pour le rôle SUPERUSER sans valider l'identité de l'appelant. Sur une instance liée à 0.0.0.0 ou publiée via un reverse proxy sans authentification supplémentaire, tout client Internet peut demander un jeton.
• /api/v1/validate/code — Accepte du code Python pour validation et l'exécute dans le processus serveur. Avec un jeton SUPERUSER, l'appelant peut soumettre du code arbitraire et obtenir une exécution dans le contexte applicatif Langflow.

La chaîne est assez courte pour être scriptée en quelques requêtes HTTP. Cela compte pour la détection : vous ne cherchez pas un dropper malware multi-étapes. Vous cherchez deux chemins API appelés en séquence depuis une adresse qui n'a aucune raison de parler à votre plateforme d'agents.

Langflow a déjà failli sur les frontières d'authentification

CVE-2026-9198 n'est pas la première fois que la surface API de Langflow traite « connecté » comme un interrupteur binaire sans demander qui s'est connecté. Des avis antérieurs sur la même ligne de produit documentaient l'absence d'authentification sur des routes administratives et des valeurs par défaut dangereuses laissant des fonctions de développement actives dans des déploiements de forme production.

Ce schéma doit guider la priorisation. Un CVSS 9,8 dans un projet OSS de niche peut perdre sa place dans la file face à une faille d'un éditeur plus visible — jusqu'à ce que vous cartographiiez où Langflow tourne. S'il détient des clés API de production pour CRM, ticketing, dépôts de code ou recherche interne, le rayon d'impact correspond à une compromission de coffre de secrets CI/CD même si l'inventaire d'actifs le classe sous « outillage IA ».

Traitez Langflow exposé sur Internet comme un TeamCity ou une appliance VPN exposée : restreignez l'accès réseau, désactivez les points de terminaison de commodité, et supposez que l'instance stocke des identifiants qui valent la peine d'être volés.

Ce que les attaquants obtiennent après la RCE

L'exécution de code à distance sur Langflow n'est pas un état final. C'est un point de départ pour :

• Lire les variables d'environnement et fichiers de configuration contenant les clés de fournisseurs LLM, secrets client OAuth et identifiants de connecteurs.
• Modifier des flows pour exfiltrer prompts, réponses ou documents joints transitant par la plateforme.
• Utiliser l'hôte comme sortie pour des outils secondaires — scanner des réseaux internes depuis un hôte qui peut se trouver dans un VLAN développeur avec une portée plus large qu'une couche web typique.
• Planter une persistance dans les définitions de flow ou hooks de démarrage qui survivent à un redémarrage de conteneur jusqu'à ce que quelqu'un inspecte le graphe, pas seulement la tag d'image.

Les plateformes d'agents agrègent la confiance. En compromettre une instance produit souvent des clés utilisables ailleurs, d'où l'échéance fédérale de trois jours plus courte que bien d'autres entrées KEV.

KEV CISA et l'horloge BOD 26-04

L'inclusion au KEV le 4 août avec remédiation due le 7 août signale que la CISA traite la RCE non authentifiée sur une infrastructure d'agents OSS largement déployée comme un risque immédiat, non comme un élément de maintenance planifiée. Les agences fédérales doivent corriger ou atténuer dans la fenêtre BOD ; le secteur privé doit y lire une pression d'exploitation plutôt qu'un calendrier qui ne le concerne pas.

Atténuation avant mise à niveau :

• Passer à Langflow 1.10.1 ou ultérieur sur chaque instance on-premises ou auto-hébergée.
• Définir LANGFLOW_AUTO_LOGIN=false même sur les builds corrigés, sauf workflow documenté exigeant le contraire.
• Supprimer l'ingress public — si les développeurs ont besoin d'accès, placez Langflow derrière votre VPN ou couche d'accès zero trust protégée par SSO plutôt qu'un enregistrement DNS direct.
• Renouveler chaque secret que Langflow peut lire après toute exploitation confirmée ou suspectée, en commençant par les clés LLM et connecteurs SaaS.

Signaux de détection et de recherche

Schémas de journaux concrets à exploiter :

• Requêtes non authentifiées ou nouvellement authentifiées vers /api/v1/auto_login depuis des plages IP non d'entreprise, surtout si le volume augmente après publication du PoC.
• Appels séquentiels à /api/v1/validate/code avec des corps POST volumineux ou obfusqués peu après création d'une session auto_login.
• Flow JSON nouveaux ou modifiés contenant des nœuds HTTP inattendus, invocations shell ou connexions sortantes vers des hôtes inconnus.
• Anomalies d'exécution de processus sur l'hôte Langflow — processus fils python lancés par le serveur applicatif hors fenêtres de déploiement connues.
• Connexions sortantes du conteneur ou VM Langflow vers des sites de paste, fournisseurs VPS ou hébergement proche du Tor peu après la séquence API ci-dessus.

Les données de scan Internet type Shodan servent à la découverte — de nombreuses organisations apprennent qu'elles exécutent Langflow via un scan externe avant leur inventaire d'actifs. La découverte interne doit inclure les registres de conteneurs et namespaces Kubernetes étiquetés expérimentation ; ces environnements héritent souvent de chemins réseau proches de la production.

Enrichir les adresses sources des journaux Langflow

Une fois les adresses IP sources candidates identifiées sur les tentatives auto_login, l'enrichissement sépare vos propres testeurs de pénétration du spray d'exploitation Internet.

• Passez les hits externes par des recherches de réputation IP pour vérifier le contexte d'hébergement, les comportements de scan antérieurs et l'association à une activité d'exploitation connue.
• Pour les callbacks ou domaines intégrés dans des modifications de flow malveillantes, utilisez le renseignement domaine et l'historique DNS.
• Traitez l'ensemble par recherches en masse lors de la revue de semaines de journaux d'accès — les déploiements Langflow sur IP publiques accumulent vite du trafic de sonde après inscription KEV.
• Alimentez les résultats dans votre SIEM via l'API pour que la prochaine alerte Langflow porte le même contexte automatiquement.
• Suivez CVE-2026-9198 dans CVE Watch avec l'évolution EPSS pour reprioriser face aux autres entrées KEV du même cycle de correctifs.

Si vous récupérez scripts ou binaires déposés sur l'hôte Langflow, les recherches par hash de fichier aident à déterminer si la charge correspond à un PoC public ou à un kit de suivi personnalisé.

Posture réseau pour les plans de contrôle d'agents

La leçon plus large de CVE-2026-9198 est architecturale. Les plateformes d'agents LLM, orchestrateurs de workflow et interfaces d'automatisation « internes seulement » rejoignent les concentrateurs VPN et interfaces de gestion à distance sur la liste des actifs qui ne doivent jamais avoir une IP publique sans couche d'authentification supplémentaire.

Posture minimale :

• Refus d'ingress par défaut sur les ports Langflow au pare-feu ; autoriser uniquement depuis les réseaux administratifs.
• Désactiver auto-login et autres valeurs par défaut développeur dans la gestion de configuration production, non dans des variables d'environnement ad hoc posées lors d'un hackathon.
• Surveiller la sortie des hôtes Langflow avec la même attention que les serveurs de build — les deux détiennent des secrets et joignent des API internes.
• Inclure les plateformes d'agents dans le périmètre de gestion des vulnérabilités même si l'équipe sécurité ne les a pas déployées ; les projets shadow IA sont du shadow IT avec des clés API attachées.

Si l'enrichissement confirme une exploitation, menez une réponse à incident en supposant le vol d'identifiants jusqu'à preuve de renouvellement des clés. Le point de terminaison validate/code donne à l'attaquant du Python interactif sur l'hôte ; traitez tout secret lisible par le processus comme compromis.

Langflow 1.10.1 ferme la chaîne. Il ne répond pas à la question de savoir si quelqu'un a déjà utilisé l'accès SUPERUSER pour copier vos identifiants de connecteur en juillet. Corrigez, désactivez auto_login, cherchez dans les journaux, enrichissez les hits — dans cet ordre, sans attendre la prochaine fenêtre de maintenance pour traiter un plan de contrôle d'agents comme l'actif de périphérie qu'il est devenu.