CVE-2026-9198 : Langflow a généré des jetons de superutilisateur pour n’importe qui, puis a exécuté ce qu’ils envoyaient

Le bulletin d'IBM concernant CVE-2026-9198 décrit une prise de contrôle de Langflow OSS en deux requêtes : un appel au point de terminaison d'auto-connexion de la plateforme renvoie un jeton bearer de superutilisateur à quiconque le demande, et un second appel envoie du code Python au point de terminaison de validation du code, qui l'exécute. L'éditeur classe les deux moitiés de la chaîne sous des identifiants distincts — CVE-2026-9103 pour l'absence d'authentification, CVE-2026-8481 pour l'exécution — et évalue la combinaison à 9,8 selon CVSS 3.1, exploitable par le réseau sans privilèges ni interaction de l'utilisateur. Les déploiements par défaut des versions 1.0.0 à 1.10.0 sont affectés ; le correctif est la version 1.10.1, et IBM n'indique aucun contournement. L'agence américaine Cybersecurity and Infrastructure Security Agency a ajouté la CVE à son catalogue Known Exploited Vulnerabilities le 4 août 2026, avec une échéance fédérale de remédiation au 7 août. La fiche, ses balises de gravité et de préjudice, ainsi que les entrées enregistrées autour d'elle sont conservées dans the Orca AI Incident Archive, qui répertorie cet incident aux côtés du reste de la série.

La chaîne, en trois bulletins IBM

IBM publie cette faille sous la forme de trois documents plutôt qu'un seul, et c'est en les lisant ensemble que le mécanisme devient lisible. Toute la chaîne est CVE-2026-9198, un problème d'injection de code relevant de CWE-94, noté 9,8 avec le vecteur AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H — joignable par le réseau, faible complexité, aucun privilège, aucune interaction utilisateur, et un impact élevé sur la confidentialité, l'intégrité et la disponibilité. Sa première moitié, CVE-2026-9103, correspond à une absence d'authentification pour une fonction critique relevant de CWE-306, également notée 9,8. Sa seconde moitié, CVE-2026-8481, relève à nouveau de CWE-94 mais est notée 9,9 : AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H, des privilèges faibles plutôt qu'aucun, et un périmètre modifié.

Le 9.9 est la partie honnête de l’arithmétique. Le point de terminaison de validation de code n’a jamais été ouvert aux inconnus de lui-même — IBM le décrit comme une faille qui permettait à « tout utilisateur authentifié d’exécuter des commandes système arbitraires avec tous les privilèges du processus serveur Langflow ». Ce qui rend la chaîne non authentifiée, c’est la première moitié : le point de terminaison d’auto-connexion, qui, selon IBM, « émet des jetons bearer de superutilisateur à longue durée de vie sans exiger d’authentification lorsque la configuration AUTO_LOGIN est activée (activée par défaut) ». Le bulletin ajoute que les jetons ont une durée de vie de 365 jours, et signale une seconde voie d’exposition qui reçoit moins d’attention — des paramètres par défaut permissifs de partage de ressources entre origines autorisant des origines génériques avec identifiants, ce qui, selon IBM, « pourrait permettre le vol de jetons à la volée depuis des sites web arbitraires ».

La moitié consacrée à l'exécution est la partie sur laquelle il vaut la peine de s'attarder. Le résumé d'IBM indique que le validateur « compilait et exécutait le code soumis par l'utilisateur, y compris les évaluations au moment de la définition de fonction telles que les arguments par défaut et les décorateurs », et qu'un attaquant pouvait donc faire passer en contrebande une expression exécutable dans un paramètre par défaut ou dans un décorateur. Ce n'est pas une figure de style à propos de code non sûr : un décorateur est évalué lorsque le def englobant est construit, si bien qu'une requête dont le seul objectif déclaré est de vérifier la syntaxe d'une fonction exécute tout de même ce qui y est attaché. L'avis chaîné d'IBM dit d'ailleurs la même chose en une seule proposition — la validation et l'exécution étaient une seule et même opération. Le correctif consigné dans le bulletin CVE-2026-8481 consistait à « supprimer l'exécution de code du chemin de validation et à n'effectuer que des contrôles de compilation ».

Une petite divergence mérite d’être consignée, car elle a une incidence sur la chasse. Le bulletin en chaîne indique le point de terminaison de jeton comme /api/v1/auto_login, et la Cloud Security Alliance ainsi que Field Effect font de même ; le bulletin distinct d’IBM sur CVE-2026-9103 l’indique comme /api/v1/login/auto_login. Les deux documents IBM décrivent le même point de terminaison et aucun des deux ne se trompe sur le comportement. Le chemin d’exécution est écrit à l’identique partout : POST /api/v1/validate/code.

D'où viennent les dates

L'archive date cet enregistrement du 6 août 2026. L'entrée du catalogue de la CISA, consultée le 30 octobre 2026, indique que l'ajout a été effectué le 4 août 2026 et fixe l'échéance de remédiation au 7 août. La couverture environnante se situe de part et d'autre de la date de l'archive plutôt qu'à cette date : Field Effect a publié le 5 août, et cvetodo ainsi que l'équipe nationale de réponse aux urgences informatiques de Thaïlande ont tous deux publié le 7 août. Une inscription au catalogue, l'échéance qu'elle produit et les articles qui en parlent sont trois événements différents, donc ces dates ne se contredisent pas — mais l'écart de deux jours entre le champ de l'archive et celui de la CISA est la raison de consulter le catalogue lorsque le jour exact compte.

La divulgation est plus difficile à cerner, et les sources sont réellement en désaccord. La page du bulletin d'IBM relative à la CVE en chaîne affiche une date de publication initiale au 2 juillet 2026 et une date de modification au 17 août 2026. Field Effect situe la divulgation d'IBM au 2 juillet. La note de recherche du Cloud Security Alliance du 18 août situe la divulgation, et la publication de la version 1.10.1 qui l'accompagne, au 17 juillet ; cvetodo dit la même chose. Quinze jours séparent les deux interprétations et aucun des deux documents n'est approximatif, donc cet article ne tranche pas entre elles. Ce qui est établi dans les deux cas, c'est que le correctif a été publié avant l'inscription au KEV, et que la version 1.10.1 est celle qui le contenait.

Ce que l’entrée de la CISA indique précisément, dans ses propres champs, est plus restrictif que son titre. Le produit figure sous le fournisseur IBM avec le produit Langflow ; la faille est décrite comme une faille « qui permet à des attaquants non authentifiés de parvenir à une exécution complète de code à distance sur les déploiements Langflow par défaut » ; l’utilisation connue dans des campagnes de rançongiciels est consignée comme étant Inconnue ; le triage forensique est marqué comme requis au titre de la BOD 26-04 ; et l’action requise consiste à appliquer les mesures d’atténuation conformément aux instructions du fournisseur, ou à cesser d’utiliser le produit lorsque les mesures d’atténuation ne sont pas disponibles.

Le registre d'exploitation

L'inscription de la CISA affirme que la faille a été exploitée dans la nature. Les preuves publiques qui étayent cette affirmation sont plus ténues que ne le laisse penser le 9,8. Ni IBM ni la CISA n'ont nommé un acteur de menace ni publié de détails sur une campagne observée — Field Effect l'affirme sans détour, et rien dans les trois bulletins d'IBM ni dans l'entrée KEV ne le contredit.

Ce qui existe à la place, ce sont des données de télémétrie de fournisseurs rapportées de seconde main. La note de la Cloud Security Alliance cite KEVIntel à l'appui de l'affirmation selon laquelle des tentatives d'exploitation ont été enregistrées à partir de « environ le 6 juillet 2026 », soit des semaines avant la divulgation selon le propre calcul de l'alliance, et selon laquelle, à la mi-août, le cumul des tentatives avait atteint les centaines, provenant de plusieurs centaines d'adresses internet uniques réparties dans des dizaines de pays. Ces chiffres proviennent d'une seule société de surveillance et n'apparaissent dans aucune autre source examinée pour cet article. Ils sont rapportés ici, non corroborés.

La date de début mérite qu’on y regarde à deux fois. Si les tentatives ont réellement commencé vers le 6 juillet, cela se situe quatre jours après la date du bulletin indiquée sur la page d’IBM, et onze jours avant la date du 17 juillet donnée par deux autres sources. La télémétrie ne confirme donc ni n’infirme l’une ou l’autre des dates de divulgation ; la Cloud Security Alliance propose les deux explications sans en choisir une, décrivant l’activité précoce soit comme une découverte indépendante par des scanners opportunistes, soit comme une fuite de détails techniques avant une divulgation coordonnée.

Le code d'exploit public est la partie la mieux documentée. Field Effect attribue la description publique de cette chaîne à « une preuve de concept publique publiée en juillet 2026 » au sein du dépôt github.com/0xdak/CVE-2026-9198_exploit, et indique que le code démontre l'obtention d'un jeton de superutilisateur via le point de terminaison d'auto-connexion, puis son utilisation contre le point de terminaison de validation. Field Effect ne relie pas l'auteur de ce dépôt à une exploitation observée, et cet article non plus. Aucune source examinée ne rapporte non plus un vol confirmé d'identifiants sur un hôte exploité : la description de la collecte d'identifiants qui accompagne généralement les failles Langflow est une évaluation de ce que détient un tel hôte, présentée ci-dessous, et non une conclusion concernant une victime nommée dans ce dossier.

Établi, rapporté et non établi

• Établi : CVE-2026-9198 enchaîne une absence d’authentification dans le point de terminaison de connexion automatique avec une exécution de code dans le point de terminaison de validation de code ; IBM classe cette chaîne à 9,8 au titre de CWE-94 et ses deux composantes à 9,8 et 9,9 ; les déploiements par défaut de Langflow OSS versions 1.0.0 à 1.10.0 sont affectés sous Windows, macOS et Linux ; 1.10.1 est le correctif et IBM ne publie aucun contournement ; et CISA a ajouté la CVE au catalogue KEV avec une échéance fédérale fixée au 7 août 2026. Les trois bulletins IBM sont les documents de référence et ils concordent entre eux sur le mécanisme.

• Reformulé de manière indépendante.ThaiCERT a reproduit la même chaîne à deux points de terminaison, le même score de 9,8, la même plage affectée et le même correctif 1.10.1 dans son avis du 7 août 2026, et y a ajouté un contrôle réseau absent des bulletins IBM : maintenir l'interface d'administration de Langflow hors d'Internet, et n'y accéder que via un VPN ou une liste blanche d'adresses stricte. Il s'agit là d'une corroboration de la façon dont l'avis a été interprété, par un organisme gouvernemental sans lien avec la formulation du fournisseur — non d'une découverte indépendante de la faille.

• Signalé, non corroboré.Tous les décomptes d’exploitation : des centaines de tentatives, plusieurs centaines d’adresses, des dizaines de pays, à partir du 6 juillet environ. Il s’agit des chiffres d’une seule société de surveillance, relayés par un organisme de recherche. L’inscription de la CISA confirme que l’exploitation a bien eu lieu sans en préciser l’ampleur, et aucune deuxième source de télémétrie n’apparaît dans les éléments examinés ici.

• Non établi. Aucune victime nommée et aucun acteur nommé. Aucune attribution à un État ni à un groupe criminel. Aucun chiffre confirmé du nombre d’instances Langflow accessibles depuis Internet — cvetodo a rapporté le 7 août qu’IBM n’avait pas répondu aux questions sur l’ampleur de l’exploitation — et aucune déclaration de fournisseur ne l’a quantifiée depuis. L’archive classe cette fiche au niveau de confiance A et ne la marque pas comme contestée, et rien de ce qui a été examiné ici ne la conteste ; les lacunes sont des lacunes dans les preuves publiques, non dans l’affirmation selon laquelle la faille existe et a été utilisée.

• Exclu délibérément.L'avis de ThaiCERT décrit également, au cours de la même semaine, un balayage automatisé piloté par IA, mais il le rattache à un autre produit du même lot CISA, et non à Langflow. Il ne constitue pas une preuve concernant cet enregistrement et n'est pas utilisé ici comme telle.

Qu'est-ce qui a changé après l'introduction en bourse ?

La solution corrective du fournisseur consiste en une incrémentation de version, rien de plus. Le tableau des produits concernés d’IBM liste Langflow OSS 1.0.0 à 1.10.0, désigne la 1.10.1 comme correctif et indique « None » dans le champ des solutions de contournement — dans les trois bulletins. Le bulletin CVE-2026-8481 décrit la modification : le validateur a cessé d’exécuter et a commencé à compiler. Le bulletin CVE-2026-9103, qui couvre la partie connexion automatique, ne détaille pas son correctif avec autant de précision, et aucun document IBM examiné ici ne date la publication de la version 1.10.1.

Les recommandations de tous les autres vont plus loin que celles du fournisseur. La Cloud Security Alliance recommande de mettre à niveau, puis de vérifier à l'exécution que le point de terminaison d'auto-connexion n'émet plus de jetons aux appelants non authentifiés, plutôt que de se fier à la chaîne de version — la raison invoquée étant que les correctifs Langflow précédents ont été livrés avec des corrections incomplètes. Elle recommande également de définir explicitement le paramètre d'environnement LANGFLOW_AUTO_LOGIN sur false, afin que la plateforme exige de véritables identifiants au lieu d'en générer, et de considérer toute instance exposée à Internet depuis début juillet comme compromise dans l'attente d'un examen des journaux, avec une rotation des identifiants pour tout ce à quoi l'instance pouvait accéder : clés des fournisseurs de modèles, identifiants de base de données et clés de services cloud. ThaiCERT ajoute la moitié réseau — aucune interface d'administration sur l'Internet public, VPN ou liste d'autorisation uniquement. Les deux sont les recommandations des chercheurs. IBM n'en publie aucune.

Une mention de crédit figure au dossier. La reconnaissance d’IBM attribue le rapport à Harish Kolla, identifiant GitHub Har1sh-k. La Cloud Security Alliance, dans sa note du 18 août, classe CVE-2026-9198 comme la quatrième faille Langflow distincte, non authentifiée ou permettant un contournement d’autorisation, à avoir atteint le catalogue de la CISA en environ cinq mois, en nommant les trois identifiants antérieurs ; selon son interprétation, ce schéma reflète une remédiation fragmentaire répétée d’un même modèle d’authentification et d’exécution de code, plutôt que des défauts sans lien. Cette formulation est l’évaluation de l’alliance, présentée dans une note de recherche ; il ne s’agit pas d’une conclusion d’un auditeur indépendant, et aucune source examinée ici ne fait état d’une réponse publique des mainteneurs à ce sujet.

Ce que l’inscription au KEV règle et ne règle pas

Le catalogue de la CISA constitue une assertion d’exploitation observée, et non un rapport d’incident, et cette entrée s’en tient à cette forme. Il indique que la faille a été utilisée ; il ne précise ni contre qui, ni par qui, ni à quelle fréquence. L’utilisation par des ransomwares est consignée comme « Unknown ». Rien n’est quantifié. Ce que la fiche tranche, en revanche, c’est l’unique question à laquelle un score de gravité ne peut répondre : la faille est-elle passée d’une preuve de concept fonctionnelle à une utilisation réelle ? Pour les organisations hors du champ de la BOD 26-04 — soit la majeure partie du monde —, l’échéance du 7 août n’emporte aucune obligation, et le fait qui la sous-tend conserve le même poids que celui qu’il aurait eu avec une obligation.

La Cloud Security Alliance tire de la même entrée la conclusion opérationnelle suivante : qu’une inscription au catalogue KEV est un signal fiable que l’exploitation a dépassé le stade de la preuve de concept, et que, pour cette faille, elle est arrivée environ un mois après les premières tentatives enregistrées. Quiconque a attendu le catalogue avant de procéder au triage, selon cette lecture, répondait déjà à un incident plutôt qu’il ne le prévenait. Savoir si cela décrit un déploiement particulier est une question à laquelle ses journaux répondront — la paire de points de terminaison à rechercher est celle documentée par IBM, et le dossier ne nomme aucune victime permettant de vérifier la réponse.