CVE-2026-0768 : un zero-day Langflow resté huit mois sans correctif est passé en exploitation de masse

Rapport CTI technique du 5 septembre 2026

Résumé exécutif

VulnCheck a signalé le 1er septembre 2026 l'exploitation active de CVE-2026-0768, une exécution de code à distance non authentifiée notée CVSS 9.8 dans Langflow, la plateforme low-code de construction de workflows LLM. Le défaut se trouve dans le validateur de code de l'éditeur de composants personnalisés : un paramètre code fourni par l'utilisateur atteint exec() sans validation, et le processus tourne en général sous root. Toutes les versions jusqu'à 1.4.2 incluse sont concernées. La chronologie de divulgation mérite d'être regardée en face : le bug a été signalé via la Zero Day Initiative en juillet 2025, puis publié comme zero-day sans correctif en janvier 2026 sous la référence ZDI-26-034. Huit mois se sont écoulés entre cette publication et le début de l'exploitation de masse.

Les premières détections remontent au 29 août 2026. VulnCheck comptabilisait plus de cinquante hits en quelques heures le 30 août, puis 360 le lundi suivant, depuis une vingtaine d'adresses sources réparties sur plus de six pays, avec un trafic majoritairement russe visant exclusivement des canaries au Royaume-Uni. Le comportement observé n'est pas du minage opportuniste mais de la reconnaissance et de la collecte d'identifiants : lecture des variables d'environnement LANGFLOW_SUPERUSER, OPENAI_API*, AWS_ACCESS*, AWS_SECRET*, lecture de /root/.cache/langflow/secret_key, vérification de l'accès .ssh et de la taille de .bash_history. Langflow cumule désormais douze vulnérabilités exploitées dans la nature depuis 2025, et VulnCheck a relevé plus de 15 000 exploitations réussies sur trois d'entre elles. La plateforme n'est plus une cible d'opportunité, c'est devenue une infrastructure de collecte de credentials.

Chronologie

Fiche vulnérabilité (format fiche CTI)

CVE-2026-0768 | CVSS 9.8 | Langflow, éditeur de composants personnalisés, toutes versions jusqu'à 1.4.2 incluse

Injection de code (CWE-94) sur le point d'entrée de validation du code des composants personnalisés. Langflow permet à l'utilisateur d'écrire des composants Python directement dans l'interface, et propose une validation syntaxique avant enregistrement. Cette validation ne se contente pas de parser : la chaîne fournie est passée à l'exécution Python sans neutralisation. Le point d'entrée n'exige pas d'authentification, ce qui rend l'exploitation triviale pour quiconque atteint le port d'écoute. Les déploiements conteneurisés par défaut exécutant le service sous root, l'exécution obtenue l'est également.

Conditions d'exploitation : accès réseau à l'instance, aucune authentification, aucune interaction utilisateur, complexité faible. La requête est un simple POST HTTP portant le paramètre code. Aucun prérequis de configuration particulier.

PoC disponible : oui. L'avis ZDI-26-034 décrit le mécanisme depuis janvier 2026, et des exploits publics circulent pour plusieurs des CVE Langflow de la même famille, notamment CVE-2025-3248 dont la logique est très proche. L'exploitation observée dans la nature est directe, une seule requête suffit.

Patch : migrer vers une version postérieure à 1.4.2. Cette CVE figure dans un ensemble de douze vulnérabilités Langflow exploitées, dont CVE-2026-0769, CVE-2025-3248 et CVE-2026-5027 qui totalisent plus de 15 000 exploitations réussies selon VulnCheck. Une mise à jour vers la dernière version disponible est la seule réponse cohérente, corriger une CVE à la fois n'a pas de sens sur ce produit.

CVE-2026-66066 | CVSS 9.5 | Ruby on Rails, Active Storage avec libvips

Mentionnée ici parce que VulnCheck l'a détectée en exploitation dans la même fenêtre, sur des canaries à Singapour, en Israël et au Royaume-Uni, avec un trafic issu d'une unique adresse IP française et un C2 vers un hôte en Israël. Elle permet la lecture arbitraire de fichiers puis la fuite du secret_key_base, de la clé maître Rails et des credentials cloud, jusqu'à l'exécution de code. Détail opérationnel utile : VulnCheck indique avoir testé un serveur en 8.1.3.1 corrigé et constaté que le correctif bloque la lecture de fichier via libvips mais ne neutralise pas la désérialisation Marshal de la clé de variation, le gadget RCE s'exécutant toujours avec une signature valide. Plus de 7 100 instances Rails vulnérables étaient exposées début août 2026.

Diagramme de la chaîne d'attaque

Reconstitution à partir des relevés VulnCheck du 29 août au 1er septembre 2026 et de l'avis ZDI-26-034.

Analyse technique

Étape 1 : une fonctionnalité qui exécute du code par conception

Langflow existe pour permettre à un utilisateur de composer des chaînes LLM en assemblant des briques, et il autorise l'écriture de composants Python personnalisés. Cette capacité est le produit, pas un accident. Le problème naît de la validation : pour signaler à l'utilisateur si son composant est syntaxiquement correct, l'application transmet la chaîne à Python. Une validation propre s'arrête à ast.parse, qui construit l'arbre syntaxique sans jamais évaluer. Le validateur de Langflow va plus loin et exécute.

C'est le même schéma que CVE-2025-3248 avant lui, sur le même produit, et c'est ce qui explique le décompte de douze CVE exploitées. La surface n'est pas une erreur isolée dans une fonction, c'est une architecture où plusieurs chemins convergent vers une exécution Python à partir d'entrées contrôlées, avec des points d'entrée dont l'exigence d'authentification est incohérente d'un endpoint à l'autre.

Étape 2 : atteindre le point d'entrée sans authentification

Le point de validation est accessible sans jeton. Une requête POST portant le champ code suffit, sans préalable, sans session, sans en-tête particulier. Pour un attaquant qui scanne, la signature est simple à automatiser et le taux de conversion élevé, ce qui explique la montée de 50 à 360 détections en deux jours sur un simple parc de canaries.

La population exposée est significative. VulnCheck situe la majorité des hôtes Langflow vulnérables aux États-Unis, en Allemagne, en Malaisie, au Brésil et en Inde. Ce sont typiquement des instances déployées en quelques minutes pour prototyper un agent, publiées sur une IP publique sans reverse proxy, puis oubliées.

Étape 3 : reconnaissance orientée secrets, pas cryptominage

Le comportement post-exploitation observé sur cette campagne se distingue des vagues précédentes. Caitlin Condon, VP threat research chez VulnCheck, décrit un mélange de reconnaissance et de collecte d'identifiants. Les requêtes des attaquants interrogent les variables d'environnement LANGFLOW_SUPERUSER, OPENAI_API*, AWS_ACCESS* et AWS_SECRET*, lisent /root/.cache/langflow/secret_key, testent l'accès à .ssh et mesurent la taille de .bash_history.

Chacun de ces éléments a une valeur précise. LANGFLOW_SUPERUSER donne l'accès administratif à l'instance et donc aux workflows qui y sont définis. Le secret_key de Langflow protège les identifiants stockés dans la base de l'application, c'est-à-dire les clés d'API des fournisseurs de modèles, des bases vectorielles et des connecteurs configurés par l'utilisateur. Les variables AWS_* ouvrent le compte cloud. La taille de .bash_history est un test de qualification : un historique volumineux signale une machine réellement utilisée par un opérateur humain, donc une cible qui mérite qu'on y revienne, plutôt qu'un honeypot ou un conteneur éphémère.

Une plateforme d'orchestration IA concentre par construction les credentials de tout ce à quoi elle est connectée. Compromettre le Langflow revient à récupérer, en un point, les accès à l'ensemble de la chaîne applicative en aval.

Étape 4 : ce que fait le reste de l'écosystème d'attaquants sur Langflow

Les autres campagnes documentées par VulnCheck sur le même produit donnent une idée de la suite probable. Sur une exploitation de CVE-2026-5027, les attaquants ont déposé un collecteur de credentials en Python, des agents proxy et SimpleHelp pour l'accès distant. Sur un autre cas, CVE-2025-3248 a servi à enrôler la machine dans un botnet de minage Monero. Dans cette même intrusion, l'opérateur a désactivé auditd, créant un angle mort forensique, puis a exploité CVE-2026-0769 pour déposer un fichier .sysd, avant de pivoter en scannant d'autres cibles pour étendre l'opération de minage.

Le motif est clair pour qui doit défendre : il n'y a pas un acteur derrière Langflow mais plusieurs, avec des objectifs différents, qui exploitent le même parc mal tenu. Une instance exposée finit compromise, la seule question est par qui.

Étape 5 : la fenêtre de huit mois

Le point le plus instructif de ce dossier est temporel. Signalement en juillet 2025, publication en zero-day en janvier 2026 faute de correctif de l'éditeur, exploitation de masse fin août 2026. Le détail technique était public depuis huit mois avant que les premiers scans n'apparaissent. Cette latence contredit l'intuition selon laquelle une divulgation publique déclenche l'exploitation dans les heures qui suivent, motif pourtant vérifié sur d'autres dossiers récents.

L'explication la plus plausible tient à la valeur perçue de la cible plutôt qu'à la difficulté technique. Les plateformes d'orchestration IA ont pris de la valeur au fil de 2026, à mesure que les organisations y ont branché des clés d'API et des accès cloud réels. Les attaquants sont revenus fouiller les avis publics une fois que le butin en valait la peine. Pour un défenseur, la conséquence pratique est qu'un avis ZDI non corrigé de janvier n'est pas un dossier clos en septembre.

Indicateurs de compromission

Les adresses IP sources précises ne sont pas publiées par VulnCheck, la volumétrie et l'origine géographique le sont. Ne construisez pas de blocage sur la seule géolocalisation.

MITRE ATT&CK

VulnCheck ne publie pas de cartographie ATT&CK formelle pour cette campagne. Le tableau ci-dessous est notre lecture technique des comportements décrits.

Remédiation : checklist opérationnelle

1. Inventorier les instances Langflow de l'organisation, y compris celles montées par des équipes produit ou data hors du périmètre géré. C'est le point qui coince en pratique, ces déploiements sont rarement dans la CMDB.
2. Mettre à jour vers une version postérieure à 1.4.2, en visant la dernière disponible. Vu le décompte de douze CVE exploitées, viser un correctif unitaire n'a pas de sens sur ce produit.
3. Retirer toute instance Langflow de l'exposition Internet directe. Placer un reverse proxy avec authentification devant l'application, ou la restreindre à un réseau interne accessible par VPN.
4. Considérer comme compromise toute instance qui a été exposée sans correctif depuis le 29 août 2026, et traiter le dossier en réponse à incident plutôt qu'en simple patch management.
5. Faire tourner l'ensemble des secrets accessibles depuis l'hôte : clés d'API des fournisseurs de modèles, clés AWS, secret_key Langflow, identifiants de bases vectorielles, clés SSH présentes sur la machine.
6. Réinitialiser le compte LANGFLOW_SUPERUSER et auditer les workflows définis dans l'instance, un attaquant ayant l'accès administratif a pu y insérer des composants persistants.
7. Ne plus exécuter le conteneur Langflow sous root. Contraindre l'utilisateur du service, retirer les capabilities inutiles, et ne pas injecter les credentials cloud dans l'environnement du processus.
8. Vérifier l'intégrité d'auditd et de la journalisation sur les hôtes concernés, la désactivation de l'audit fait partie du répertoire observé.
9. Chasser les artefacts listés plus haut, en particulier les processus enfants du service Langflow et la présence d'un fichier .sysd.
10. Traiter en parallèle CVE-2026-66066 côté Rails si l'organisation utilise Active Storage avec libvips, en tenant compte du fait qu'un serveur en 8.1.3.1 conserve le gadget de désérialisation Marshal selon les tests de VulnCheck.
11. Appliquer la même logique d'inventaire et d'exposition aux autres plateformes d'orchestration IA du parc. Le raisonnement des attaquants porte sur la catégorie, pas sur le produit.

Sources

• Attackers Exploit Critical Langflow and Rails Flaws in Credential-Probing and C2 Activity, The Hacker News
• Hackers Start Exploiting Critical Langflow Vulnerability, SecurityWeek
• Avis ZDI-26-034, Zero Day Initiative
• Pwning the AI Stack, VulnCheck
• Langflow Remote Code Execution Vulnerability Exploited in Attacks (CVE-2026-0768), Qualys ThreatPROTECT
• CVE-2026-0768, National Vulnerability Database
• Critical Langflow Flaw Exploited as Attacks on AI Platform Rise, Dark Reading