Langflow sous attaque : une faille RCE expose des clés OpenAI, AWS et des identifiants root

Des acteurs malveillants exploitent CVE-2026-0768, une vulnérabilité critique de Langflow permettant d’exécuter du code Python à distance, sans authentification. Les attaques ciblent principalement les secrets conservés dans l’environnement : clés API OpenAI, identifiants AWS, tokens d’administration et données susceptibles de faciliter l’extension de la compromission.

L’information a été publiée le 1er septembre 2026. VulnCheck a détecté l’activité grâce à des honeypots situés au Royaume-Uni, en enregistrant initialement au moins 50 tentatives au cours d’un week-end dont la date n’a pas été précisée. La chercheuse Caitlin Condon a ensuite fait état d’un total de 360 attaques observées.

Le validateur de Langflow exécute du code contrôlé par l’attaquant

Langflow est un framework open source basé sur Python, conçu pour créer des applications d’intelligence artificielle au moyen d’une interface low-code. Il permet de relier des modèles de langage, des prompts, des bases de données, des API et d’autres outils afin de créer des agents, des chatbots et des systèmes RAG.

La vulnérabilité concerne l’éditeur de composants personnalisés et, plus précisément, l’endpoint utilisé pour valider le code. Le paramètre code, contrôlable par l’utilisateur, n’est pas correctement vérifié avant d’être utilisé pour exécuter du code Python.

Un attaquant peut donc envoyer une requête spécialement conçue à l’endpoint validate et obtenir l’exécution d’instructions arbitraires. Aucune information d’authentification ni interaction d’un utilisateur légitime n’est nécessaire.

Le code est également exécuté dans le contexte de l’utilisateur root. Ce détail transforme la faille, qui ne permettrait autrement qu’un simple accès applicatif, en une compromission potentiellement complète de l’hôte ou du conteneur exécutant Langflow.

CVE-2026-0768 est classée CWE-94, qui correspond à une génération incorrecte de code entraînant une injection de code. Son identifiant Zero Day Initiative est ZDI-CAN-27322, avec l’avis ZDI-26-034.

Le vecteur attribué par la CNA Zero Day Initiative est le suivant :

CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

Le score associé est de 9,8 sur 10. La NVD n’a toutefois pas encore publié sa propre évaluation numérique : dans sa fiche, le score de base NVD est indiqué comme N/A.

Versions concernées et mise à jour vers la 1.11.6

Le périmètre des versions vulnérables n’est pas décrit de manière parfaitement cohérente. La NVD indique Langflow 1.4.2 dans son tableau, tandis que d’autres rapports incluent également les versions antérieures à la 1.4.2.

Afin d’éviter une interprétation trop restrictive, les administrateurs ne devraient pas se contenter de vérifier la présence de la seule version 1.4.2. La mesure recommandée consiste à mettre directement à niveau Langflow vers la version 1.11.6, présentée comme la version corrigeant l’ensemble des vulnérabilités connues du produit.

CVE-2026-0768 ne figure pas parmi les vulnérabilités répertoriées dans le catalogue Known Exploited Vulnerabilities (KEV) de la CISA. Il n’existe donc pas, pour cette CVE, de date d’ajout au catalogue ni d’échéance fédérale spécifique.

L’absence du catalogue KEV ne signifie toutefois pas l’absence d’exploitation. Dans ce cas, l’exploitation a été observée directement au moyen de honeypots, alors qu’aucun proof of concept public pour CVE-2026-0768 ne semble disponible.

Le trafic provenait principalement de Russie, mais cet élément ne permet pas d’attribuer la campagne. Aucun groupe précis n’a été identifié et l’origine des connexions pourrait s’expliquer par l’utilisation de serveurs compromis, de proxys ou d’infrastructures achetées par les attaquants.

Les attaquants recherchent les secrets Langflow, AWS et OpenAI

Après avoir obtenu l’exécution de code, les attaquants effectuent une reconnaissance de l’hôte et interrogent les variables d’environnement. Cette stratégie est particulièrement efficace contre les applications d’IA, qui reçoivent souvent leurs secrets directement via la configuration d’exécution, des fichiers .env ou des systèmes d’orchestration.

Parmi les éléments recherchés figurent :

• les variables LANGFLOW_SUPERUSER ;
• les variables portant le préfixe OPENAI_API* ;
• les identifiants AWS_ACCESS* ;
• les secrets AWS_SECRET* ;
• le fichier /root/.cache/langflow/secret_key ;
• le contenu ou l’accessibilité du répertoire .ssh ;
• la taille et la disponibilité de .bash_history.

Le vol d’une clé OpenAI peut permettre une consommation frauduleuse des API, l’accès aux ressources associées au compte ou l’exécution de requêtes aux frais de la victime. Les conséquences dépendent des autorisations et des services liés à la clé.

Les identifiants AWS peuvent avoir un impact encore plus important. Lorsqu’ils sont associés à des rôles IAM surdimensionnés, ils peuvent permettre d’accéder à des systèmes de stockage, des bases de données, des workloads, des gestionnaires de secrets et des infrastructures de calcul.

Les tokens superuser de Langflow sont eux aussi sensibles. Un attaquant pourrait les utiliser pour intervenir sur les workflows, lire des configurations, manipuler des composants ou préparer des accès supplémentaires.

Les clés exposées doivent être considérées comme compromises, même lorsque les journaux ne montrent pas d’utilisation immédiate. Elles peuvent être conservées puis réutilisées ultérieurement depuis d’autres infrastructures.

Comment rechercher une éventuelle compromission

La mise à jour corrige la vulnérabilité, mais ne supprime pas les accès éventuellement déjà obtenus. Sur une instance exposée, en particulier lorsqu’elle est accessible depuis Internet, il est nécessaire d’associer au correctif une démarche de réponse à incident.

Dans les journaux applicatifs et ceux du reverse proxy, il convient de rechercher des requêtes inhabituelles vers les endpoints de validation, en accordant une attention particulière aux paramètres code et exec_globals. Les payloads contenant des instructions Python, des appels shell, des accès au système de fichiers ou une énumération des variables d’environnement sont également importants.

Sur le système, il faut vérifier :

• les lectures inattendues de /root/.cache/langflow/secret_key ;
• les accès à .ssh et .bash_history ;
• les processus Python ou shell lancés par le service Langflow ;
• les processus enfants incompatibles avec le fonctionnement normal ;
• les nouveaux utilisateurs, clés SSH, tâches cron ou autres mécanismes de persistance ;
• les fichiers créés ou modifiés dans des emplacements inattendus ;
• les connexions sortantes vers des destinations inconnues ;
• les modifications apportées aux conteneurs, aux images et aux volumes persistants.

Les services externes doivent également faire l’objet de vérifications. Les journaux AWS doivent être analysés afin d’identifier les authentifications provenant d’adresses IP, de régions ou de user agents inhabituels, ainsi que les modifications IAM ou les accès anormaux aux données. Pour OpenAI, il faut contrôler l’utilisation, la consommation et la facturation associées aux clés présentes sur l’instance.

Correctif, isolation et rotation complète des identifiants

La priorité consiste à mettre Langflow à niveau vers la version 1.11.6. Si cette opération ne peut pas être effectuée immédiatement, l’instance doit être retirée de l’exposition publique ou protégée au moyen d’un pare-feu, de security groups et de contrôles sur le reverse proxy.

Les endpoints de validation, d’authentification automatique, d’upload et de gestion des flows ne devraient pas être directement accessibles depuis des réseaux non fiables. Cette restriction réduit la surface d’exposition, mais ne remplace pas la mise à jour.

Après une éventuelle exploitation, il faut au minimum renouveler :

1. les clés et secrets AWS ;
2. les clés API OpenAI ;
3. les identifiants et tokens superuser Langflow ;
4. les clés applicatives locales ;
5. les identifiants SSH accessibles par le processus ;
6. les autres tokens présents dans les variables d’environnement ou les fichiers de configuration.

Il est également recommandé de réexaminer les autorisations IAM en appliquant le principe du moindre privilège. Si une instance ne peut être ni mise à jour ni isolée correctement, la solution la plus sûre consiste à cesser de l’utiliser.

Une succession de vulnérabilités déjà exploitées contre Langflow

CVE-2026-0768 intervient après plusieurs vulnérabilités de Langflow ajoutées au catalogue KEV de la CISA.

CVE-2026-33017, une RCE dans l’endpoint de construction des flows publics, figure dans le catalogue KEV depuis le 25/03/2026, avec une échéance fédérale fixée au 08/04/2026. La vulnérabilité concerne langflow < 1.8.2 et permet de transmettre à exec() du code Python intégré à des nœuds contrôlés par l’attaquant.

CVE-2026-55255 figure dans le catalogue KEV depuis le 07/07/2026, avec une remédiation requise avant le 10/07/2026. Il s’agit d’une IDOR, corrigée dans la version 1.9.1, qui permettait à un utilisateur authentifié d’exécuter des flows appartenant à d’autres comptes.

CVE-2026-0770, ajoutée au catalogue KEV le 21/07/2026 avec une échéance au 24/07/2026, exploite le paramètre exec_globals de l’endpoint validate afin d’obtenir une exécution de code à distance avec les privilèges root. Les versions langflow <= 1.7.3 sont concernées.

CVE-2026-9198 a été ajoutée au catalogue KEV le 04/08/2026, avec une échéance au 07/08/2026. La chaîne d’exploitation combine l’émission de tokens SUPERUSER via /api/v1/auto_login et l’exécution de code au moyen de /api/v1/validate/code ; elle concerne langflow < 1.10.1.

Le catalogue mentionne également CVE-2025-3248, ajoutée le 05/05/2025 avec une échéance au 26/05/2025, et qui aurait été utilisée dans des campagnes de ransomware.

Cette succession d’incidents met en évidence un risque opérationnel concret pour les installations Langflow exposées. Appliquer uniquement le correctif ne suffit pas lorsqu’une RCE avec les privilèges root a déjà été exploitée : il faut renouveler les secrets, effectuer un triage forensique et vérifier l’ensemble de l’infrastructure connectée.