Des attaquants exploitent une vulnérabilité non authentifiée d’exécution de commandes à distance dans le framework open source Langflow, destiné à créer des applications d’intelligence artificielle, afin de voler des identifiants, des jetons et des clés d’accès, notamment des clés OpenAI et AWS. La vulnérabilité porte le numéro CVE-2026-0768 et présente un niveau de gravité critique. Elle se situe dans l’outil de validation du code au sein de l’éditeur de composants personnalisés.
La société de renseignement sur les menaces VulnCheck a détecté cette activité par l’intermédiaire de ses honeypots au Royaume-Uni, où elle a enregistré au moins 50 tentatives d’exploitation durant le week-end. Caitlin Condon, chercheuse principale en sécurité de l’entreprise, a déclaré que l’activité s’était ensuite intensifiée, portant le total des attaques observées à 360 tentatives, le trafic d’attaque provenant principalement de Russie.
Comment la vulnérabilité est-elle exploitée ?
Le problème permet à l’attaquant d’exécuter du code arbitraire sans authentification et avec les privilèges root. La faille est liée à la manière dont est traité le paramètre code envoyé au point de terminaison validate ; le texte fourni par l’utilisateur n’est pas correctement vérifié avant d’être utilisé pour exécuter du code Python.
Selon Condon, les attaquants commencent par des opérations de reconnaissance, puis interrogent les variables d’environnement à la recherche d’identifiants administratifs ou de clés d’authentification hautement privilégiées propres à Langflow, ainsi que de secrets AWS et de clés d’API OpenAI. Les requêtes observées comprenaient des variables telles que LANGFLOW_SUPERUSER, OPENAI_API*, AWS_ACCESS* et AWS_SECRET*, ainsi que le fichier /root/.cache/langflow/secret_key. Elles vérifiaient également la possibilité d’accéder à SSH et la taille du fichier .bash_history.
Pourquoi cette actualité est-elle importante ?
L’impact de la compromission ne se limite pas au serveur Langflow lui-même. La plateforme, développée en Python et fonctionnant selon une approche low-code, sert à créer des applications, des agents, des conversations et des systèmes de génération augmentée par récupération, en reliant des modèles de langage, des bases de données, des interfaces de programmation et d’autres composants. Ainsi, l’accès aux variables d’environnement ou aux fichiers de secrets peut transformer le serveur en point de départ vers les services d’intelligence artificielle ou les services cloud qui lui sont associés.
Les faits disponibles indiquent que le problème s’inscrit dans une tendance plus large, car d’autres vulnérabilités de Langflow ont déjà été exploitées au cours de la même année. CVE-2026-33017 a été exploitée environ un jour après sa divulgation pour exécuter des scripts Python et voler des fichiers ENV et des bases de données, tandis que CVE-2026-5027 a été utilisée pour écrire des fichiers arbitraires et que CVE-2026-55255 a été exploitée pour accéder aux workflows d’autres utilisateurs, voler des données sensibles et déployer des logiciels malveillants ultérieurs. CVE-2026-0770 a également fait l’objet de tentatives d’exécution de commandes avec les privilèges root et d’extraction d’identifiants cloud et de données de conteneurs. La CISA a ensuite mis en garde contre l’exploitation de CVE-2026-9198 après la publication de plusieurs modèles de preuve de concept.
Que doivent faire les utilisateurs ?
La source recommande aux utilisateurs de Langflow de passer à la version 1.11.6, qui corrige toutes les failles connues mentionnées dans l’article. Selon Condon, aucun modèle d’exploitation public connu de CVE-2026-0768 n’existait au moment de la préparation du rapport. Toutefois, la détection d’une exploitation réelle signifie que l’absence de modèle publié ne dispense pas de considérer les systèmes concernés comme exposés.
Lecture éditoriale de certi.news : le risque pratique provient ici de la combinaison de trois facteurs clairement établis par la source : l’exécution de code sans authentification, les privilèges root et la présence de secrets opérationnels dans l’environnement ciblé. La source ne prouve pas que les attaques détectées ont entraîné des compromissions confirmées d’environnements de production particuliers. Ce point nécessite donc une vérification indépendante. Les opérateurs devraient également examiner les journaux et les secrets exposés lorsqu’ils traitent des versions concernées.