Langflow CVE-2026-0770 : RCE root non authentifiée sur l'outillage LLM (CVSS 9.8)

Langflow est un constructeur visuel d'applications LLM — une interface en glisser-déposer pour composer des chaînes LangChain sans écrire de code. Comme tout l'outillage IA apparu ces deux dernières années, il a connu une adoption fulgurante, souvent déployé rapidement, souvent exposé, et rarement passé au crible d'une revue de sécurité.

Deux vulnérabilités Langflow ont rejoint le catalogue CISA KEV en juillet 2026, dont une RCE non authentifiée aboutissant à une exécution de code en root (CVSS 9.8).

Le détail qui devrait alerter : CVE-2026-0770 a été publiée le 23 janvier 2026 et n'est entrée au KEV que le 21 juillet — six mois plus tard. Un tel écart signifie généralement une chose : le parc exposé était encore suffisamment large en juillet pour justifier une alerte.

Les deux CVE

CVE-2026-0770 — exec_globals vers du root

Description NVD :

Langflow exec_globals Inclusion of Functionality from Untrusted Control Sphere Remote Code Execution Vulnerability. This vulnerability allows remote attackers to execute arbitrary code on affected installations of Langflow. Authentication is not required to exploit this vulnerability.

The specific flaw exists within the handling of the exec_globals parameter provided to the validate endpoint. The issue results from the inclusion of a resource from an untrusted control sphere. An attacker can leverage this vulnerability to execute code in the context of root.

Le mécanisme

L'endpoint validate de Langflow sert à valider du code — typiquement les snippets Python que l'utilisateur intègre dans ses composants de flow. Pour cela, il doit nécessairement les évaluer.

Le paramètre exec_globals contrôle l'espace de noms global fourni à cette évaluation. En laissant l'appelant définir cet espace de noms, l'application lui permet d'injecter les références de son choix dans le contexte d'exécution — et notamment de reconstruire un accès aux primitives d'import et d'exécution système que la validation était censée interdire.

Deux aggravants s'ajoutent :

• Aucune authentification requise sur l'endpoint
• Exécution en root — Langflow est très majoritairement déployé en conteneur Docker avec l'utilisateur par défaut, c'est-à-dire root

Le problème de fond de cette classe d'outils

Langflow, comme la plupart des constructeurs de flows LLM, a une caractéristique inconfortable : exécuter du code arbitraire fourni par l'utilisateur est sa fonction, pas son bug. Un composant Python personnalisé dans un flow, c'est du code que l'application doit faire tourner.

La sécurité de ces outils repose donc entièrement sur l'hypothèse que « l'utilisateur est de confiance » — hypothèse qui s'effondre dès que l'instance est joignable sans authentification, ou dès qu'un contournement d'autorisation existe. Ce qui nous amène à la seconde CVE.

CVE-2026-55255 — exécuter les flows des autres

NVD n'a pas publié de score. Description CISA :

Langflow contains an authorization bypass through user-controlled key vulnerability which allows an authenticated attacker to execute any flow belonging to another user by specifying the victim's flow ID in the request.

Le motif est classique — une référence directe à un objet sans contrôle de propriétaire (IDOR) : l'application vérifie que tu es authentifié, mais pas que le flow_id que tu réclames t'appartient.

L'impact est spécifique au contexte LLM, et il est sous-estimé si on le lit comme un simple IDOR. Exécuter le flow d'un autre utilisateur, c'est :

• Consommer ses clés API LLM — chaque exécution facture le propriétaire du flow, pas l'attaquant
• Accéder aux données que le flow manipule : bases vectorielles, documents indexés, connecteurs vers des systèmes internes
• Utiliser les credentials embarqués dans le flow (connexions base de données, API tierces, webhooks)
• Sur une instance multi-tenant, traverser la frontière entre tenants

Un flow LLM d'entreprise contient typiquement bien plus qu'un prompt : des connecteurs authentifiés vers le SI, un accès à une base vectorielle nourrie de documents internes, et des clés API à forte valeur.

Produits et versions affectés

Pour CVE-2026-55255, NVD n'expose pas encore la version corrigée — consulte les releases du projet.

Vérifie ta version :

# Docker
docker inspect langflow --format '{{.Config.Image}}'

# Pip
pip show langflow | grep -i version

# Via l'API
curl -s http://localhost:7860/api/v1/version

Exploitation et impact

Pourquoi l'outillage IA est massivement scanné

Cette catégorie d'outils réunit tous les facteurs de risque :

• Déploiement rapide, sécurisation reportée — on installe pour prototyper, l'instance reste
• Exposition fréquente — pour partager une démo avec l'équipe ou un client, on publie sur une IP publique
• Authentification souvent désactivée en développement, puis oubliée
• Exécution en root dans les images Docker par défaut
• Secrets de forte valeur : clés OpenAI, Anthropic, Bedrock, credentials de bases vectorielles et de connecteurs SI

Le résultat, après compromission, va bien au-delà du serveur : les clés API LLM se revendent, et une clé active peut brûler plusieurs milliers d'euros de crédit en quelques heures.

Chaîne d'attaque

1. Découverte d'une instance Langflow exposée (l'interface est identifiable à sa signature HTTP)
2. CVE-2026-0770 : requête vers validate avec un exec_globals forgé → exécution de code en root, sans compte
3. Extraction des variables d'environnement et de la base Langflow → clés API LLM, credentials des connecteurs
4. Énumération et exécution des flows existants (CVE-2026-55255 si un compte a été obtenu)
5. Pivot vers les systèmes internes atteints par les connecteurs des flows
6. Persistance : création d'un flow malveillant déclenché par webhook, indiscernable d'un usage légitime

Détection et IOC

Journaux applicatifs

# Appels à l'endpoint validate — rares en usage normal
docker logs langflow 2>&1 | grep -iE "validate|exec_globals"

L'endpoint validate est sollicité lors de l'édition de composants dans l'interface. Un volume d'appels sans session d'édition correspondante, ou des appels contenant exec_globals, sont anormaux.

Journaux du reverse proxy

grep -E "POST .*(validate|/api/v1/validate)" /var/log/nginx/access.log | \
  grep -vE "^(10\.|172\.16\.|192\.168\.|127\.)"

Tout appel depuis une IP externe mérite investigation.

Sur le conteneur

# Processus enfants inattendus
docker exec langflow ps -ef | grep -vE "python|uvicorn|gunicorn|ps|grep"

# Fichiers récents
docker exec langflow find /tmp /app -type f -mtime -60 -newer /etc/hostname 2>/dev/null | head -30

Le signal financier

Souvent le premier indicateur détecté en pratique : une hausse inexpliquée de la facturation OpenAI, Anthropic ou Bedrock. Vérifie tes consommations sur les six derniers mois — la CVE est publique depuis janvier.

Audit des flows

Liste les flows existants et cherche ceux que personne ne revendique, en particulier ceux déclenchables par webhook. C'est le mécanisme de persistance le plus discret sur ce type d'outil.

Mitigation et patch

1. Mettre à jour

# Docker
docker pull langflowai/langflow:1.7.3
docker compose up -d

# Pip
pip install --upgrade "langflow>=1.7.3"

2. Retirer l'instance d'Internet

C'est la mitigation qui vaut le plus, ici et pour les prochaines CVE de cette catégorie d'outils. Une instance Langflow n'a rien à faire sur une IP publique. VPN, mTLS, ou proxy authentifiant.

3. Activer l'authentification et vérifier qu'elle est effective

Beaucoup d'instances tournent avec l'auto-login activé, hérité du mode développement. Confirme que l'authentification est requise sur tous les endpoints, pas seulement sur l'interface.

4. Ne pas exécuter en root

# docker-compose.yml
services:
  langflow:
    user: "1000:1000"
    read_only: true
    tmpfs:
      - /tmp

Ça ne corrige pas la CVE mais réduit très sensiblement l'impact d'une exploitation — la différence entre « code exécuté en root » et « code exécuté sous un compte sans privilège dans un conteneur en lecture seule ».

5. Réponse à incident — la CVE est publique depuis janvier

Si ton instance a été exposée depuis janvier 2026, considère la compromission comme plausible :

1. Fais tourner toutes les clés API LLM manipulées par Langflow, côté fournisseurs
2. Fais tourner les credentials des connecteurs utilisés par tes flows (bases de données, API internes, webhooks)
3. Audite la facturation LLM des six derniers mois
4. Revois la liste des flows et supprime ceux qui ne sont pas revendiqués
5. Fais tourner les credentials de la base Langflow elle-même

Pourquoi surveiller en continu votre stack IA

L'outillage IA se déploie plus vite qu'il ne se sécurise. Langflow, Flowise, Dify, AnythingLLM, LiteLLM, Ollama, vLLM : ces briques manipulent des clés API à très haute valeur et des connecteurs authentifiés vers le SI, mais n'apparaissent dans aucun inventaire de sécurité classique. Elles ne sont pas dans le CMDB, elles n'ont pas de propriétaire déclaré, et souvent l'équipe sécurité ignore leur existence.

CVE-2026-0770 en est l'illustration : publiée en janvier, entrée au KEV en juillet — six mois durant lesquels une RCE root non authentifiée était documentée publiquement et exploitable.

Avec cveo.tech, inventorie tes outils d'infrastructure IA au même titre que tes applications métier et reçois une alerte automatique dès qu'une CVE critique cible une de tes versions exactes — pour ne pas découvrir la faille six mois après sa publication, par le montant de ta facture OpenAI.