360 tentatives d’exploitation en quelques jours — la faille Langflow qui vise vos clés API

La plupart des alertes critiques concernent des logiciels que vous savez avoir installés. Celle-ci est différente, et c’est ce qui la rend intéressante : la question n’est pas de savoir s’il faut corriger, mais de découvrir que vous êtes concerné.

CVE-2026-0768 est une vulnérabilité d’exécution de code à distance dans Langflow, l’outil visuel de construction de flux et d’agents s’appuyant sur des modèles de langage. Elle est notée 9.8 sur l’échelle CVSS, ce qui la place tout en haut de la gravité, et l’exploitation est déjà active dans la nature.

Le mécanisme est simple à décrire. Le défaut se trouve dans le validateur de code de l’éditeur de composants personnalisés. Une chaîne fournie par l’utilisateur n’est pas correctement validée avant d’être utilisée pour exécuter du code Python. Résultat : un attaquant fait exécuter le code de son choix, avec les droits root, sans posséder le moindre compte.

Cette combinaison — aucune authentification requise, droits maximaux obtenus — est la pire qui existe. Il n’y a pas d’étape intermédiaire à franchir, pas de privilège à escalader, pas de phase de reconnaissance longue. Une requête suffit.

Ce que montrent les leurres : une exploitation opportuniste et méthodique

Les chiffres publiés par VulnCheck donnent la mesure du phénomène : plus de 360 tentatives d’exploitation comptabilisées sur ses systèmes leurres au Royaume-Uni, l’essentiel du trafic provenant de Russie.

Un chiffre de cet ordre, sur des leurres, indique un balayage automatisé de grande ampleur. Personne ne cible spécifiquement votre entreprise : des scanners parcourent Internet à la recherche d’instances Langflow exposées et tentent l’exploitation sur tout ce qui répond. C’est une nuance importante, parce qu’elle supprime l’argument le plus répandu dans les réunions de sécurité des PME : « nous sommes trop petits pour intéresser quelqu’un ». Dans un balayage automatisé, la taille de l’entreprise n’est pas un critère de sélection. L’exposition l’est.

Le plus instructif reste ce que les attaquants font ensuite. Les requêtes observées relèvent de la reconnaissance et de la collecte d’identifiants : interrogation des variables d’environnement, recherche de clés secrètes et d'accès SSH. Pas de rançongiciel, pas de chiffrement immédiat, pas de message d’extorsion.

Cette orientation est parfaitement rationnelle du point de vue de l’attaquant. Une instance Langflow n’a presque aucune valeur en tant que machine : peu de puissance, pas de données clients stockées durablement, aucun intérêt à la chiffrer. En revanche, elle concentre les identifiants d’accès à tout ce qu’elle orchestre : les clés d’API des fournisseurs de modèles, les identifiants des bases de données que les flux interrogent, les jetons des services connectés.

C’est aussi ce qui rend cette compromission particulièrement pernicieuse : rien ne casse. Aucun service ne tombe, aucun message ne s’affiche, aucun utilisateur ne se plaint. Les clés partent, et l’entreprise l’apprend plusieurs semaines plus tard — parfois par une facture de consommation anormale chez un fournisseur de modèles, parfois jamais.

Le vrai problème français : personne ne sait qu’il en a une

Corriger Langflow est trivial. Découvrir qu’une instance tourne dans votre entreprise l’est beaucoup moins, et c’est là que se joue l’essentiel du risque pour les PME et ETI françaises.

Langflow appartient à une famille d’outils que les équipes déploient elles-mêmes. Un développeur veut prototyper un agent, une équipe marketing veut automatiser un traitement de contenu, un analyste veut brancher un modèle sur une base interne. L’installation prend quelques minutes, souvent en conteneur, souvent sur une machine qui traîne, et parfois exposée à Internet « juste le temps de la démonstration ».

La démonstration se termine. L’instance, elle, reste en ligne. Et comme elle n’a jamais figuré dans un inventaire, elle n’apparaît dans aucun tableau de suivi des correctifs. Nous décrivions déjà ce mécanisme dans notre analyse des risques du shadow AI et des outils LLM non autorisés en PME ; la CVE-2026-0768 en fournit l’illustration la plus coûteuse à ce jour.

Un point mérite d’être clarifié pour éviter la confusion : Langflow avait déjà été ajouté au catalogue KEV du CISA début août 2026 pour une vulnérabilité distincte. Il ne s’agit pas de la même faille. Une instance corrigée à ce moment-là n’est pas protégée contre CVE-2026-0768. Cette répétition est en soi un signal : un composant qui accumule des failles critiques exploitées en quelques semaines mérite une décision d’architecture, pas seulement un correctif de plus.

Notre avis d’expert : trois lectures de cet incident

Premièrement, la surface d’attaque de l’IA n’est pas le modèle, c’est l’outillage autour. Le débat public sur la sécurité de l’IA porte sur les injections de prompt et le comportement des modèles. Pendant ce temps, les compromissions réelles que nous traitons passent par l’infrastructure banale qui entoure ces modèles : une interface d’administration exposée, un validateur de code trop permissif, une variable d’environnement en clair. CVE-2026-0768 n’est pas une faille d’IA. C’est une faille d’exécution de code non validée, comme on en voyait déjà il y a vingt ans, dans un outil qui se trouve manipuler de l’IA.

Deuxièmement, la révocation doit précéder la preuve. Le réflexe naturel, face à une instance potentiellement compromise, est de chercher d’abord à établir s’il y a eu exfiltration. C’est une erreur de séquencement. Établir cette preuve est long, souvent impossible avec la journalisation par défaut, et pendant ce temps les clés restent valides. Considérez toute clé présente sur une instance exposée comme compromise et révoquez-la immédiatement. Le coût d’une révocation inutile se compte en minutes de gêne ; le coût d’une révocation tardive se compte autrement.

Troisièmement, l’exposition est une décision, pas un état de fait. Aucune de ces instances n’avait besoin d’être accessible depuis Internet. Elles le sont devenues par commodité, souvent pour permettre à un collègue de tester depuis chez lui. La mesure qui aurait neutralisé cette vulnérabilité pour l’immense majorité des entreprises françaises ne coûte rien : ne pas publier le port, et passer par un accès authentifié. Elle est plus efficace que n’importe quel correctif, parce qu’elle protège aussi contre la prochaine faille, celle qui n’a pas encore de numéro.

Plan d’action : ce qu’il faut faire aujourd’hui

Pour identifier les instances, trois recherches donnent une réponse en quelques heures : le port 7860 sur votre parc, les conteneurs dont l’image contient langflow y compris sur les postes de développement, et votre inventaire d’actifs exposés à Internet. Ajoutez-y la méthode la plus efficace, et la plus négligée : demandez aux équipes qui expérimentent l’IA. Dans la majorité des cas que nous traitons, la réponse arrive par cette voie avant le résultat du scan.

Au-delà de cette faille précise, l’enseignement structurel est celui de la visibilité. Une organisation qui ne sait pas ce qui est exposé sur son périmètre ne peut pas se prononcer sur son exposition, quel que soit le budget consacré aux outils. C’est la démarche que nous détaillons dans notre méthode pour auditer la surface d’attaque externe d’une entreprise en 7 étapes, et dans notre guide sur la gestion et la rotation des secrets, qui traite précisément du scénario où des clés se retrouvent dans un environnement qu’on croyait temporaire.

Questions fréquentes

Qu’est-ce que la CVE-2026-0768 et pourquoi est-elle critique ?

C’est une exécution de code à distance non authentifiée dans Langflow, notée 9.8 sur l’échelle CVSS. Le défaut se situe dans le validateur de code de l’éditeur de composants personnalisés : une chaîne fournie par l’utilisateur n’est pas correctement validée avant d’être utilisée pour exécuter du Python. Un attaquant fait donc exécuter du code arbitraire avec les droits root, sans aucun compte. Trois caractéristiques la rendent dangereuse : aucune authentification requise, droits maximaux obtenus directement, et un outil souvent déployé hors du périmètre supervisé par la DSI.

Comment savoir si une instance Langflow tourne dans mon entreprise ?

C’est la vraie difficulté, car Langflow est fréquemment installé par une équipe métier ou un développeur qui prototype un agent, sans passer par la DSI. Trois vérifications répondent vite : rechercher le port 7860 et les conteneurs dont l’image contient langflow sur tout le parc, postes de développement inclus ; interroger l’inventaire des actifs exposés à Internet, car une instance montée pour une démonstration y reste souvent longtemps après ; et poser directement la question aux équipes qui expérimentent l’IA, voie par laquelle la réponse arrive généralement le plus vite.

Que cherchent concrètement les attaquants sur les instances compromises ?

Les observations publiées décrivent de la reconnaissance et de la collecte d’identifiants plutôt que du chiffrement : variables d’environnement, clés secrètes, accès SSH. C’est cohérent, car une instance Langflow contient presque toujours les clés d’API des fournisseurs de modèles, souvent des identifiants de bases ou de services internes que les flux interrogent, parfois des jetons de messagerie ou de stockage. La machine vaut peu, ce qu’elle détient vaut beaucoup. C’est aussi pourquoi la compromission reste longtemps invisible : rien ne casse, les clés partent simplement ailleurs.

Quelles mesures prendre en priorité si une instance est exposée ?

Dans cet ordre : couper immédiatement l’exposition Internet, même si le correctif est prévu dans la journée ; considérer toutes les clés présentes comme compromises et les révoquer sans attendre une preuve d’exfiltration difficile à établir ; appliquer la mise à jour de l’éditeur ; rechercher dans les journaux les requêtes vers l’éditeur de composants personnalisés et les connexions sortantes inhabituelles ; enfin surveiller l’usage des clés révoquées côté fournisseur, une consommation anormale étant souvent le premier signal exploitable.

Source de l’événement : CVE-2026-0768, exécution de code à distance non authentifiée dans le validateur de code de l’éditeur de composants personnalisés de Langflow (CVSS 9.8), exploitation active constatée ; plus de 360 tentatives relevées par VulnCheck sur ses systèmes leurres au Royaume-Uni, trafic majoritairement en provenance de Russie, activité orientée reconnaissance et collecte d’identifiants (variables d’environnement, clés secrètes, accès SSH). Éléments tels que rapportés publiquement début septembre 2026. Analyse, priorisation et recommandations : WebGuard Agency.