if ( !emtpy($headline_subheadline ) ) : ?>
Le prochain désastre en matière de sécurité de l’IA ne commencera peut-être pas par votre modèle, mais par l’outil low-code auquel votre équipe a fait confiance pour le construire.
endif; ?>
La catégorie de logiciels d’entreprise qui connaît actuellement la croissance la plus rapide est également la moins surveillée du point de vue de la sécurité. Les plates-formes d’applications d’IA (des outils qui permettent aux équipes de créer, de connecter et d’automatiser des flux de travail basés sur l’IA sans écrire beaucoup de code) arrivent dans les environnements de production plus rapidement que les équipes de sécurité ne peuvent les évaluer. Ils se connectent à vos API, vos bases de données, vos identifiants cloud et vos comptes de service IA. Et les attaquants l’ont remarqué.
Langflow est l’une de ces plateformes les plus largement déployées. Il est open source, low-code et conçu pour permettre aux équipes de glisser-déposer des modèles d’IA, des API et des sources de données dans des applications fonctionnelles et des flux de travail d’agent sans lourdes dépenses d’ingénierie. Cette accessibilité est exactement la raison pour laquelle elle s’est développée si rapidement. C’est aussi pourquoi ce qui s’est passé fin août est important pour toute organisation qui l’a déployé.
Le 29 août 2026, l’équipe de renseignement sur les menaces de VulnCheck a commencé à observer des tentatives d’exploitation continues contre les instances Langflow accessibles sur Internet. La vulnérabilité exploitée – CVE-2026-0768, avec un score CVSS de 9,8 – se trouvait dans la base de code de Langflow avant sa divulgation publique en tant que jour zéro en janvier 2026. L’exploitation qui a commencé fin août n’a pas ralenti.
Ce que fait réellement la vulnérabilité
L’éditeur de composants personnalisés de Langflow comprend un point de terminaison de validation, une fonctionnalité qui permet aux développeurs de tester un extrait de code avant de l’ajouter à un flux de travail. L’idée est raisonnable : donner aux utilisateurs un moyen de vérifier leur logique avant qu’elle ne soit lancée en production. La mise en œuvre est le problème.
Ce point de terminaison prend le code soumis par un utilisateur et le transmet directement dans exec() de Python. Il n’y a aucune validation de l’entrée avant l’exécution, et dans de nombreux déploiements par défaut, aucune authentification n’est requise pour atteindre le point de terminaison. Un attaquant qui peut accéder à une instance Langflow accessible sur Internet sur le réseau peut envoyer une requête contrefaite à ce point de terminaison et exécuter immédiatement du code Python arbitraire — en tant qu’utilisateur root, sans informations d’identification et sans aucune interaction de l’utilisateur requise.
Une fois à l’intérieur, la chaîne d’attaque est rapide et cohérente. Les attaquants recherchent des fichiers .env, des variables d’environnement, des clés SSH et du code source. Ils récoltent les clés API OpenAI, les informations d’identification AWS, les jetons de stockage cloud et les informations d’identification de base de données. Ces informations d’identification volées sont envoyées à une infrastructure externe et l’attaquant tente un mouvement latéral via SSH et d’autres protocoles. L’ensemble de la séquence – depuis l’exploitation initiale jusqu’à l’exfiltration des informations d’identification – laisse peu de signes au cours de l’activité normale du flux de travail de l’IA, ce qui rend la détection beaucoup plus difficile.
VulnCheck a enregistré plus de 360 tentatives d’exploitation sur ses pots de miel britanniques dans les jours qui ont suivi la divulgation publique, la majorité du trafic d’attaque provenant de Russie. Ce nombre reflète les tentatives observées contre les systèmes instrumentés. Le nombre d’attaques réussies contre des déploiements de production non instrumentés est inconnu.
Pourquoi cela devient une tendance
La vulnérabilité Langflow n’est pas apparue de manière isolée. Avant 2026, une seule vulnérabilité Langflow avait été exploitée dans la nature. Cette année, ce nombre est passé à douze. VulnCheck a enregistré plus de 15 000 tentatives d’exploitation réussies concernant trois failles Langflow associées – CVE-2026-0769, CVE-2025-3248 et CVE-2026-5027 – avant que CVE-2026-0768 ne soit ajouté à cette liste.
La raison n’est pas que Langflow soit soudainement devenu moins sécurisé. C’est que Langflow est devenu suffisamment précieux pour attaquer. Comme l’ont écrit les chercheurs de VulnCheck, l’adoption rapide des technologies d’IA a apporté des outils dont les concepteurs ont donné la priorité à l’accessibilité plutôt qu’aux principes de sécurité. Les mêmes qualités qui rendent les plates-formes d’applications d’IA attrayantes pour les équipes d’entreprise (disponibilité open source, déploiement facile, larges intégrations d’API, connexions aux services cloud et aux comptes d’IA) en font des cibles attrayantes une fois qu’une primitive d’exécution de code existe.
C’est la même dynamique qui s’est produite avec les plateformes CI/CD, puis avec les outils de gestion Kubernetes, et maintenant avec l’infrastructure de développement d’IA. La catégorie des outils se développe rapidement, les contrôles de sécurité sont à la traîne et les attaquants s’y installent une fois que la base installée est suffisamment importante pour en valoir la peine.
Une instance Langflow exposée sur Internet avec CVE-2026-0768 non corrigé n’est pas principalement un problème Langflow. Il s’agit d’un problème d’exposition des informations d’identification. La clé API OpenAI volée dans le fichier .env d’un développeur ne se soucie pas de la manière dont elle a été prise. Les informations d’identification AWS collectées à partir d’une variable d’environnement n’expirent pas lorsque le correctif est finalement appliqué. La faille Rails révélée parallèlement à cette recherche le souligne explicitement : un secret compromis reste utile jusqu’à ce qu’il soit modifié, que la vulnérabilité qui l’a exposé ait été corrigée ou non.
Trois contrôles qui comptent en ce moment
- Corrigez immédiatement et identifiez chaque instance exposée. Toutes les versions de Langflow jusqu’à la 1.4.2 incluse sont concernées. VulnCheck a commencé à observer les tentatives d’exploitation quelques heures après la divulgation publique : le délai entre la disponibilité d’un correctif et la recherche par les attaquants des instances non corrigées se mesure en heures, et non en jours. Tout déploiement Langflow accessible depuis Internet sans authentification devant le point de terminaison de validation constitue actuellement un risque actif. La première étape consiste à savoir combien d’instances existent dans votre environnement et lesquelles sont accessibles sur Internet. De nombreuses organisations découvrent lors d’incidents que les déploiements de développement et de test ont été exposés sans la visibilité de l’équipe de sécurité.
- Faites pivoter chaque identifiant ayant touché une instance Langflow exposée. Ce n’est pas facultatif même si vous pensez que votre instance n’a pas été activement exploitée. La chaîne d’attaque cible les fichiers .env, les variables d’environnement, les clés SSH et les informations d’identification cloud, éléments qui persistent sur le disque et en mémoire tout au long du fonctionnement normal de Langflow. Une clé API OpenAI ou un identifiant d’accès AWS stocké dans un environnement qui exécutait une version concernée de Langflow doit être traité comme potentiellement compromis. Faites-le pivoter. Examinez les journaux d’accès du côté du fournisseur d’informations d’identification pour les demandes que le propriétaire légitime n’a pas initiées. Les conseils de VulnCheck désignent spécifiquement les informations d’identification OpenAI et AWS comme principales cibles de la campagne observée, et la rotation des informations d’identification est le seul contrôle qui reste efficace, indépendamment du fait qu’une exploitation ait eu lieu ou non.
- N’exposez pas les plateformes de développement d’IA à Internet sans authentification. Le point de terminaison de validation de Langflow n’ayant aucune authentification dans les configurations par défaut est le catalyseur direct de cette attaque. Mais le principe est plus large : les plateformes d’applications d’IA, les outils d’automatisation des flux de travail et les environnements de développement d’agents ne sont pas des services grand public. Ils se connectent aux informations d’identification de production, aux comptes cloud et aux API internes. Les déployer avec des points de terminaison connectés à Internet et sans couche d’authentification équivaut à exposer une base de données de développement à l’Internet public. Placez ces déploiements derrière un VPN ou exigez une authentification au périmètre du réseau. Appliquez les mêmes contrôles d’accès que vous appliqueriez à toute autre infrastructure de développement interne.
Une évaluation honnête
La vulnérabilité CVE-2026-0768 dans Langflow est grave, mais le plus important est la trajectoire qu’elle représente. Douze vulnérabilités Langflow exploitées en 2026 contre une toutes les années précédentes ne sont pas une coïncidence. Cela indique que les attaquants travaillent méthodiquement sur la pile d’outils d’IA de la même manière qu’ils ont travaillé sur les outils de gestion cloud et les pipelines de développeurs au cours des années précédentes.
Les équipes de sécurité qui ont investi dans la visibilité sur leurs applications SaaS, leurs identifiants cloud et leurs pipelines de développement sont mieux placées pour détecter le mouvement latéral qui suit l’exploitation initiale. Les organisations les plus exposées sont celles qui traitent les plateformes de développement d’IA comme des outils de productivité plutôt que comme une infrastructure : elles les déploient rapidement, les connectent aux informations d’identification de production et les laissent en dehors du périmètre de sécurité qui régit tout le reste.
CVE-2026-0768 est corrigé et le correctif est disponible. Les informations d’identification collectées entre le 29 août et chaque fois que votre organisation met à jour et effectue une rotation constituent un problème différent. Celui-ci n’a pas de mise à jour du fournisseur.
