Des attaquants exploitent CVE-2026-0768 dans Langflow pour siphonner les clés OpenAI et AWS

1er septembre 2026. BleepingComputer rapporte que CVE-2026-0768, une exécution de code à distance non authentifiée dans Langflow, est exploitée en conditions réelles pour voler des identifiants. 360. C’est le nombre total de tentatives d’exploitation comptées par les honeypots de VulnCheck, qui en observaient encore 50 au seul week-end. 1.4.2. C’est la dernière version vulnérable. Pourquoi c’est important : Langflow est devenu la cible la plus martelée de l’infrastructure IA auto-hébergée, avec six failles exploitées depuis janvier 2026.

La faille : un validateur de code qui exécute au lieu de vérifier

Langflow est un framework open source en Python, à interface graphique bas code, qui sert à construire des applications IA, des agents, des chatbots et des pipelines RAG en reliant des composants — modèles de langage, prompts, bases de données, API. Le défaut CVE-2026-0768 se situe dans le validateur de l’éditeur de composants personnalisés : le paramètre code envoyé au endpoint de validation est traité sans contrôle avant d’être exécuté comme code Python. Résultat : une requête non authentifiée suffit à exécuter des commandes arbitraires avec les privilèges du processus.

Le défaut a été divulgué en janvier 2026, référencé par Trend Micro Zero Day Initiative sous ZDI-26-034, et touche Langflow jusqu’à la version 1.4.2 incluse. Il est classé critique. La nature de la brèche — une exécution sans authentification, à la racine du conteneur dans de nombreux déploiements — explique pourquoi il intéresse autant les attaquants : un seul paquet suffit à prendre la main sur toute l’instance.

Ce que les attaquants récoltent précisément

Caitlin Condon, chercheuse principale chez VulnCheck, a détaillé le comportement observé. Les requêtes d’exploitation interrogent les variables d’environnement pour extraire les identifiants administratifs : LANGFLOW_SUPERUSER, les clés OpenAI (OPENAI_API_*) et les secrets AWS (AWS_ACCESS_*, AWS_SECRET_*). Les attaquants lisent aussi /root/.cache/langflow/secret_key, vérifient l’accès SSH et la taille de l’historique .bash_history — un catalogue précis de ce qu’une instance Langflow contient de précieux.

Le trafic provient majoritairement de Russie et cible les honeypots de VulnCheck au Royaume-Uni. Aucun proof of concept public n’a encore été identifié, ce qui n’a pas empêché le passage à l’échelle : le compteur est passé de 50 à 360 tentatives en quelques jours. C’est le schéma classique d’une faille de janvier qui trouve son public une fois l’exploit industrialisé.

La sixième faille exploitée en huit mois

CVE-2026-0768 n’est pas un accident isolé : c’est le sixième défaut de Langflow exploité en 2026. En mars, CVE-2026-33017, une injection de code critique, a été exploitée dans la journée suivant sa divulgation pour exécuter des scripts Python et dérober des fichiers .env et de bases de données. Ont suivi CVE-2026-5027 (traversée de chemin pour écrire des fichiers arbitraires), CVE-2026-55255 (contournement d’authentification donnant accès aux workflows d’autres utilisateurs), CVE-2026-0770 (exécution de commandes en root), puis CVE-2026-9198, que la CISA a signalé comme exploitée après la publication de plusieurs preuves de concept.

Cette série dessine un profil clair : Langflow concentre les propriétés qui attirent les attaquants d’infrastructure IA — un déploiement simple qui se retrouve exposé par défaut, des identifiants cloud et de fournisseurs de modèles stockés en clair dans l’environnement, et une base d’utilisateurs qui privilégie la mise en route rapide à la sécurisation. Chaque correctif ouvre un nouveau cycle de recherche de la faille suivante.

La liste complète des failles exploitées tient en un tableau, et elle mérite d’être affichée telle quelle pour mesurer l’ampleur :

Le point commun de ces six failles est leur rentabilité : chacune transforme une instance exposée en point de collecte d’identifiants qui donnent ensuite accès au cloud ou au fournisseur de modèles. C’est un vol en deux temps — d’abord la machine, puis tout ce qu’elle avait le droit d’appeler.

Ce qu’il faut faire maintenant

La recommandation de Langflow est sans ambiguïté : passer à la version 1.11.6, qui corrige l’ensemble des failles connues de l’outil. Pour une équipe qui exploite déjà l’outil, la vérification de version et la détection d’exposition tiennent en quelques commandes :

# Vérifier la version installée (vulnérable : <= 1.4.2 ; corrigée : >= 1.11.6)
pip show langflow | grep -i version

# Confirmer qu'aucune instance n'est joignable depuis Internet
curl -sS --max-time 5 http://LANGFLOW-HOST:7860/api/v1/version || echo "non exposée"

Mais la mise à jour seule ne suffit pas. Une instance qui a tourné en version vulnérable a pu voir ses variables d’environnement lues : il faut traiter les secrets comme compromis et les faire pivoter — clés OpenAI, clés d’accès AWS, identifiants LANGFLOW_SUPERUSER, et la clé de signature du cache. La rotation est la partie que les équipes oublient, et c’est pourtant celle qui neutralise la récolte déjà effectuée.

Pourquoi une faille de janvier explose en septembre

CVE-2026-0768 a été divulguée en janvier et n’a été massivement exploitée que huit mois plus tard. Ce décalage entre l’avis public et l’exploitation industrialisée est la vraie fenêtre à surveiller, et elle est plus courte pour les frameworks IA auto-hébergés que pour les logiciels d’entreprise : il n’existe aucun canal de mise à jour forcée, et l’instance qui se fait piller est celle dont personne ne lit le changelog. Le corollaire est qu’un patch tardif ne protège pas contre la récolte déjà effectuée — d’où la rotation des secrets.

Comment détecter une instance déjà compromise

La faille s’inscrit dans un glissement plus large : les frameworks qui servent à construire des applications IA — Langflow, mais aussi Dify, Flowise ou n8n — stockent par nature les identifiants des fournisseurs de modèles et des clouds, ce qui en fait des cibles à plus forte valeur que les applications web classiques. Voler une base de données donne des données ; voler une instance Langflow donne les clés qui ouvrent le reste de l’infrastructure.

La mise à jour vers 1.11.6 ferme la brèche mais ne dit rien sur ce qui s’est déjà produit. La première chose à faire est d’inventorier ce que l’instance expose dans son environnement, puisque c’est précisément ce que les attaquants ont lu :

# Ce que l'attaquant a pu lire : lister les variables sensibles du conteneur
docker exec <langflow> env | grep -Ei 'OPENAI|AWS|SUPERUSER|SECRET|TOKEN'

# La clé de signature du cache : vérifier son existence et sa date de dernière lecture
ls -la /root/.cache/langflow/secret_key

Si les variables OPENAI_API_KEY, AWS_ACCESS_KEY_ID ou LANGFLOW_SUPERUSER sont présentes, partez du principe qu’elles sont compromises : pivotez-les immédiatement, avant même de patcher. Regardez aussi le trafic sortant du conteneur — une exfiltration vers un endpoint inhabituel est le signe le plus direct d’une exploitation réussie. Enfin, vérifiez l’accès SSH et l’historique .bash_history : les requêtes observées cherchaient précisément à évaluer ces deux surfaces pour préparer la persistance.

L’ordre des opérations compte : rotation des secrets d’abord, patch ensuite, puis surveillance. Inverser les deux laisse une fenêtre où les clés déjà volées restent utilisables pendant que vous croyez le problème réglé.

Verdict

Si vous exposez Langflow sur Internet, arrêtez : ce framework n’a pas vocation à être joignable publiquement. Placez-le derrière un reverse proxy avec authentification, ou restreignez-le à un réseau interne, quelle que soit la version.

Si vous l’utilisez en interne, montez à 1.11.6, puis pivotez tous les secrets qui ont pu traîner sur une instance vulnérable. La correction logicielle sans rotation des clés ne ferme que la moitié du risque.

Si vous n’utilisez pas Langflow, tirez la leçon générique : les frameworks IA auto-hébergés stockent des identifiants de fournisseurs de modèles et de cloud, ce qui en fait des cibles à forte valeur. Inventoriez ceux que vos équipes ont déployés, vérifiez leur exposition, et appliquez-leur la même exigence de patch que vos services de production.

Références

• Critical Langflow flaw exploited to steal OpenAI and AWS keys — BleepingComputer, 1er septembre 2026
• CVE-2026-0768 — NVD
• ZDI-26-034 — Trend Micro Zero Day Initiative