Langflow CVE-2026-0768 : la 12e faille Langflow exploitée dans la nature cette année

CVE-2026-0768 est une faille d'exécution de code à distance sans authentification dans Langflow, le framework visuel open source permettant d'assembler des pipelines et des agents de grands modèles de langage, et les attaquants l'exploitaient déjà dans la nature fin août 2026. La faille se trouve dans le validateur de code qui sous-tend l'éditeur de composants personnalisés de Langflow : le point de terminaison validate accepte un paramètre code et exécute le Python qu'il contient, sans authentification et, selon les termes de la Zero Day Initiative, « dans le contexte de root ». Le réseau de pots de miel Canary de VulnCheck a enregistré plus de 50 tentatives d'exploitation dans les heures suivant les premières détections du 30 août 2026, et plus de 360 d'ici le lundi 1er septembre, toutes dirigées contre des capteurs situés au Royaume-Uni ; Caitlin Condon, de VulnCheck, a indiqué que le trafic source provenait principalement de Russie. Les requêtes n'étaient pas de nature rançongiciel. Elles lisaient les variables d'environnement contenant les identifiants de superutilisateur Langflow, les clés d'API OpenAI ainsi que les clés d'accès et les clés secrètes AWS, puis elles examinaient /root/.cache/langflow/secret_key, .ssh et .bash_history. L'entrée complète de l'archive pour cet incident, y compris ses classifications de gravité, de confiance et de préjudice, figure dans l'Orca AI Incident Archive, aux côtés des autres enregistrements de vol d'identifiants et d'infrastructure d'IA qui l'entourent.

Security Affairs a publié son compte rendu le 2 septembre 2026 ; Ionut Arghire, de SecurityWeek, a signalé l’exploitation la veille, Bill Toulas, de BleepingComputer, l’a couverte cette semaine-là, et l’AI Safety Initiative de la Cloud Security Alliance a emboîté le pas le 4 septembre avec une note de recherche qui reformule le mécanisme et ajoute des recommandations. Aucun des comptes rendus examinés pour cet article n’a nommé d’organisation compromise. Tout remonte aux propres capteurs de VulnCheck et à l’avis publié par la Zero Day Initiative en janvier.

Un éditeur qui exécute ce qu’on lui demande de valider

Le principal atout de Langflow, c’est que l’on assemble une application d’IA en faisant glisser des composants sur un canevas. Les composants personnalisés sont en Python : l’éditeur permet à un utilisateur de coller du code et de cliquer sur valider, et le serveur le vérifie. Selon l’avis ZDI ZDI-26-034, cette vérification exécute le code. La phrase de cause racine de l’avis tient en une ligne — « l’absence de validation appropriée d’une chaîne fournie par l’utilisateur avant de l’utiliser pour exécuter du code Python » — et le résultat est qu’une seule requête HTTP non authentifiée exécute du Python arbitraire sur l’hôte.

Trois propriétés transforment cela en incident plutôt qu’en simple rapport de bug. Le vecteur CVSS est AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H, avec un score de 9,8 : joignable via le réseau, faible complexité, aucun privilège, aucune interaction utilisateur, et perte totale de confidentialité, d’intégrité et de disponibilité. Le contexte d’exécution est root, ce qui explique pourquoi les commandes de l’attaquant que Condon et la Cloud Security Alliance décrivent toutes deux se dirigent vers /root/.cache/langflow/secret_key — le fichier que Langflow utilise pour chiffrer les identifiants et les données de session stockés. Et le point de terminaison ne demande aucune information d’identification, donc l’exposition ne dépend que de sa joignabilité.

L’historique de la divulgation est important pour comprendre comment les choses se sont déroulées. La chronologie de ZDI indique que le rapport est parvenu au compte GitHub de Langflow le 18 juillet 2025, une demande de mises à jour le 11 septembre 2025, une demande de correctif le 10 octobre 2025, et un avis d’intention de publication en tant que zero-day le 10 décembre 2025. ZDI a publié l’avis le 9 janvier 2026. Les chercheurs crédités sont Peter Girnus, William Gamazo Sanchez et Alfredo Oliveira de Trend Research. La base de données d’avis de GitHub contient le même texte sous la référence GHSA-x5pr-rvjj-j6qm, publiée le 23 janvier 2026, classée CWE-94, et n’indique aucune plage de versions affectées. La mesure d’atténuation indiquée par ZDI n’est pas un correctif : elle consiste à « restreindre l’interaction avec le produit ».

Les rapports publics situent la plage concernée aux versions de Langflow jusqu’à la 1.4.2 incluse, la version sur laquelle le module Metasploit ajouté par la suite a été conçu et testé. C’est là que s’arrête la certitude, et la section consacrée aux correctifs ci-dessous explique pourquoi.

Ce que les détections 360 établissent et n’établissent pas

Les Canaries de VulnCheck sont des capteurs exposés à Internet, conçus pour ressembler à ce qu’un attaquant recherche. L’entreprise a observé la première exploitation de CVE-2026-0768 les 29 et 30 août 2026 : plus de 50 détections en quelques heures le dimanche, puis plus de 360 le lundi. Condon, vice-président de la recherche sur les menaces chez VulnCheck, a décrit cette activité sur LinkedIn comme « un mélange de reconnaissance et de collecte d’identifiants », ajoutant que le trafic source provenait principalement de Russie et n’avait « jusqu’à présent touché que des Canaries au Royaume-Uni ».

La séquence de commandes capturée par les capteurs est suffisamment précise pour constituer un playbook. Les attaquants ont interrogé l’environnement à la recherche de LANGFLOW_SUPERUSER, de variables correspondant à OPENAI_API, et de clés AWS_ACCESS et AWS_SECRET — les trois familles d’identifiants qu’un hôte Langflow est le plus susceptible de détenir. Ils ont lu la clé secrète mise en cache à /root/.cache/langflow/secret_key. Ils ont vérifié l’accès à .ssh et inspecté la taille de .bash_history, deux éléments qui indiquent si un opérateur peut se déplacer latéralement plutôt que simplement lire des secrets. Un rapport communautaire sur la chaîne, cité par la Cloud Security Alliance, ajoute que la même activité a recherché des secrets intégrés dans les arborescences de code source et les fichiers .env, exfiltré ce qu’elle a trouvé, et vérifié si un hôte avait déjà été compromis par un opérateur précédent avant d’ajouter sa propre persistance.

Ce que cela établit, c'est que l'exploit fonctionne, qu'il a été utilisé contre des instances Langflow exposées à Internet et que l'objectif visait les identifiants plutôt que la perturbation. Ce que cela n'établit pas, c'est l'existence d'une victime. Les canaris sont des leurres ; une détection est une requête, pas un vol confirmé. L'archive classe cet enregistrement comme un préjudice réel, et le préjudice documenté dans les sources publiques correspond à l'exécution confirmée d'un code de collecte d'identifiants contre des systèmes exposés — et non à une organisation nommée dont les clés auraient été utilisées.

Un détail contredit le récit habituel sur la divulgation. Selon VulnCheck, aucun proof-of-concept public pour CVE-2026-0768 n’existait au moment où l’exploitation a commencé. L’avis était public depuis près de huit mois et décrivait la faille avec suffisamment de précision pour que quelqu’un puisse construire un exploit à partir du texte. Selon l’interprétation de l’entreprise, telle que rapportée par The Hacker News, il s’agissait d’une dérivation indépendante plutôt que d’une réutilisation de code divulgué.

Douze failles, quinze mille tentatives — et où ces chiffres s’infléchissent

La statistique qui donne à cet incident son poids provient de VulnCheck, et il vaut la peine de la citer dans les propres termes de l’entreprise plutôt que de la paraphraser. « Avant 2026, les éléments montraient une seule vulnérabilité Langflow connue comme exploitée dans la nature », a-t-elle déclaré. « En 2026, les choses ont changé rapidement. » SecurityWeek rapporte que VulnCheck suit « 11 vulnérabilités supplémentaires ciblées et signalées comme exploitées dans la nature » au cours de 2026.

Ajoutez-les et vous obtenez douze vulnérabilités Langflow exploitées, dont l’une est antérieure à l’année. Ce n’est pas la même chose que douze en 2026, et les sources glissent entre les deux formulations. Le titre de Forkast qualifie CVE-2026-0768 de « 12e CVE exploitée de Langflow en 2026 », tandis que le corps du même article décrit la douzaine comme « 11 nouvelles vulnérabilités et une identifiée avant le début de l’année ». Le titre de la fiche reprend celui de l’article. Lu strictement, 2026 en compte onze sur douze, la douzième — celle connue avant cette année — constituant le reste.

Le chiffre de 15 000 présente un avantage comparable. SecurityWeek, The Hacker News et Forkast attribuent tous « plus de 15 000 attaques réussies » à trois vulnérabilités nommées : CVE-2026-0769, CVE-2025-3248 et CVE-2026-5027. C'est un nombre considérable, mais il s'agit d'un décompte portant sur trois CVE, et non sur l'ensemble du portefeuille 2026 de Langflow. Le présenter comme des tentatives d'exploitation visant le portefeuille — comme le fait le résumé de l'archive — est plus large que ce que VulnCheck a publié.

Les différentes entrées à l’origine de ce schéma sont documentées. CVE-2025-3248 était une faille d’injection de code dans le même point de terminaison /api/v1/validate/code, corrigée dans Langflow 1.3.0 en remplaçant l’exécution par une validation limitée à la compilation, selon l’avis GitHub GHSA-rvqx-wpfh-mfx7 cité par la Cloud Security Alliance — ce qui signifie que CVE-2026-0768 est la même catégorie de bug dans le même chemin de code, environ quatre mois après la publication de ce correctif. CVE-2026-33017, une RCE non authentifiée dans le point de terminaison public de construction de flux, a été transformée en arme dans les 20 heures environ suivant sa divulgation en mars 2026 et utilisée pour dérober des identifiants OpenAI, Anthropic et AWS avant de pivoter vers le cryptominage de Monero, selon le récit de la Cloud Security Alliance. La note du 12 juin 2026 de la même alliance couvre CVE-2026-5027, une faille de traversée de chemin dans le point de terminaison de téléversement de fichiers que les chercheurs ont liée au groupe MuddyWater parrainé par l’État iranien, et sa note du 4 septembre mentionne CVE-2026-55255, un contournement d’autorisation permettant à un utilisateur authentifié d’exécuter les flux d’un autre utilisateur, inscrit au catalogue Known Exploited Vulnerabilities de la CISA le 7 juillet 2026. Ces quatre failles partagent un même schéma : un point de terminaison qui a soit omis l’authentification, soit omis l’assainissement, dans une plateforme dont la fonction est de conserver les identifiants de tout ce avec quoi elle interagit.

Pourquoi une plateforme d'orchestration en vaut la peine

Une instance Langflow de production est configurée avec des clés d'API de fournisseurs, des identifiants cloud, des chaînes de connexion à des bases de données et des secrets d'intégration, parce que les flux qu'elle exécute en ont besoin au moment de l'appel. La compromission de l'hôte donne donc un accès opérationnel à chaque service dont l'instance stocke les identifiants. Des clés OpenAI ou Anthropic volées permettent à un attaquant de faire facturer l'inférence à la victime ou d'usurper l'identité de l'organisation en aval ; des clés AWS volées ouvrent l'accès à une infrastructure bien au-delà du conteneur Langflow. C'est ce levier, plutôt que quelque capacité propre à l'IA, que visaient les commandes observées.

L’appréciation de la Cloud Security Alliance est que la récurrence, au cours d’une même année, dans quatre sous-systèmes Langflow différents — validateur de code, point de terminaison public de construction de flux, téléversement de fichiers, exécution de workflow — indique une lacune systémique en ingénierie de sécurité plutôt qu’une série de défauts sans lien. Il s’agit de l’évaluation de l’alliance, formulée dans une note de recherche, et non d’une conclusion d’un auditeur indépendant, et Langflow n’y a pas répondu publiquement dans les éléments examinés ici.

Ce qui a été corrigé et ce qui reste ambigu

C'est le point le plus faible de l'information publique, et il vaut la peine de préciser pourquoi. L'avis de ZDI ne nomme aucune version corrigée. L'entrée de la base de données Snyk pour la CVE indique comme versions affectées toutes celles antérieures à 1.10.1 et recommande de passer à la version 1.10.1 ou ultérieure. Les articles publics, notamment ceux de SecurityWeek et Security Affairs, décrivent la plage affectée comme allant jusqu'à la version 1.4.2 incluse, mais n'identifient aucune version corrigée. La Cloud Security Alliance a noté le 4 septembre que les mainteneurs de Langflow n'avaient pas publié d'avis de sécurité dédié nommant cette CVE, et que les outils de suivi ne s'accordaient pas sur la version qui l'avait réellement corrigée — une ambiguïté qui, selon l'alliance, rappelle un précédent cas Langflow où une version annoncée comme corrigée restait exploitable.

Langflow a bien livré des correctifs dans la bonne zone, le bon jour. La version 1.11.6 a été publiée le 1er septembre 2026, le lundi où le décompte du honeypot a dépassé 360, et ses notes de version décrivent un backport de correctifs de sécurité incluant « close component code scan gaps » et « resolve annotations without execution » (pull request 14876). La version 1.12.0 a suivi ce soir-là. Le durcissement du même chemin de code s’est poursuivi ensuite : une pull request ultérieure intitulée « stop validate_code from executing imports » indique que le point de terminaison validate était encore renforcé des semaines après la première exploitation. Rien de tout cela ne constitue une déclaration du fournisseur selon laquelle CVE-2026-0768 est corrigée dans une version nommée, et aucune n’a été trouvée dans les sources citées du dossier.

Ce qui a changé côté attaquant est plus clair. Un module d’exploitation Metasploit pour la faille a été ouvert sous forme de pull request le 2 septembre 2026 — le jour même où Security Affairs a publié — et fusionné le 8 octobre 2026, testé contre Langflow 1.4.2. Quel que soit l’état de la dérivation d’origine, exploiter cette faille n’a plus exigé de travail original six semaines après le début de son exploitation.

La réponse recommandée par la Cloud Security Alliance consiste en une séquence de correctif puis de rotation plutôt qu’en un correctif seul : vérifier la version en cours d’exécution et passer à la version stable actuelle ; considérer toute instance exposée à Internet sur une version affectée comme compromise jusqu’à preuve du contraire, car l’activité observée est une collecte silencieuse plutôt qu’une perturbation visible ; et faire tourner chaque secret auquel l’instance pouvait accéder — le mot de passe superutilisateur de Langflow, les clés d’API des fournisseurs, les clés d’accès et clés secrètes AWS, ainsi que la clé secrète de Langflow elle-même — en réchiffrant les identifiants stockés plutôt qu’en se contentant de remplacer le fichier. Elle recommande également d’auditer les journaux d’accès pour rechercher les requêtes vers le point de terminaison validate, d’examiner authorized_keys pour y détecter des clés SSH inconnues et de rechercher des preuves qu’un opérateur précédent avait déjà installé une porte dérobée sur l’hôte. Lorsque la plateforme doit rester accessible, elle suggère de restreindre ou de désactiver le point de terminaison validate et de s’éloigner des clés à hauts privilèges de longue durée stockées directement dans la plateforme.

Établi, rapporté et non établi

Établi : que CVE-2026-0768 est une RCE non authentifiée dans le point de terminaison validate de Langflow qui exécute du Python en tant que root, documentée dans ZDI-26-034 et reprise sous la référence GHSA-x5pr-rvjj-j6qm ; que l'exploitation a débuté les 29 et 30 août 2026 ; que VulnCheck a enregistré plus de 50 détections en quelques heures et plus de 360 au 1er septembre, visant des capteurs britanniques, avec un trafic provenant principalement de Russie ; et que les requêtes observées ciblaient les identifiants de superutilisateur Langflow, OpenAI et AWS, ainsi que la clé secrète mise en cache, .ssh et .bash_history. Ces éléments proviennent de l'avis lui-même et de la télémétrie de VulnCheck, tels que rapportés indépendamment par SecurityWeek, Security Affairs et The Hacker News.

Rapporté, mais non vérifié de manière indépendante : chaque nombre de détections. Les 50, les 360 et les 15 000 sont les propres chiffres de VulnCheck, publiés par l'entreprise et repris par des médias qui la citent ; aucun autre réseau de pots de miel n'a publié de décompte corroborant. L'attribution à une infrastructure russe est également la lecture par VulnCheck du trafic source, et non une évaluation qu'un gouvernement ou un CERT aurait approuvée dans les documents examinés.

Non établi : qu'une organisation nommée quelconque ait perdu des identifiants d'accès. Aucune victime n'a été identifiée dans les sources du dossier. Il n'y a pas non plus de version corrigée confirmée : ZDI n'en nomme aucune, Snyk indique 1.10.1, les articles rapportent une affectation jusqu'à la version 1.4.2, et les notes de version 1.11.6 décrivent des correctifs de sécurité sans les rattacher à cette CVE. Le décompte de la « douzième faille de 2026 » n'est pas non plus cohérent en interne au sein de ses propres sources, comme indiqué ci-dessus.

La partie qui devrait inquiéter ceux qui appliquent des correctifs selon un calendrier

L'écart de huit mois constitue le constat. CVE-2026-0768 a été publiée comme zero-day le 9 janvier 2026, avec une description technique suffisamment détaillée pour pouvoir reconstruire l'exploit, et rien ne s'est produit sur les capteurs de VulnCheck avant le dernier week-end d'août. Puis plusieurs centaines de tentatives sont arrivées en trois jours, de la part d'opérateurs qui, selon l'entreprise, n'avaient aucun exploit public à copier. Ce qui a bien pu laisser ces instances sans correctif pendant huit mois de publication d'un avis critique public est exactement ce qui a rendu la faille intéressante à exploiter le jour où quelqu'un a enfin écrit le code.

Cela referme aussi une boucle ouverte par les précédentes CVE de Langflow. CVE-2025-3248 avait été corrigée en supprimant l’exécution du même chemin de validation ; CVE-2026-0768 s’exécute pourtant sur ce chemin. Un correctif qui supprime un comportement sans supprimer la décision de conception qui l’a produit fait gagner du temps, et dans ce cas il en a fait gagner environ quatre mois.