L'endpoint de build public de Langflow : RCE non authentifiée armée en 20 heures

De quoi s’agit-il ?

Langflow est un framework open source largement déployé, à interface visuelle, pour construire des agents LLM et des pipelines RAG (Retrieval-Augmented Generation). CVE-2026-33017, divulguée le 17 mars 2026, est une faille d’exécution de code à distance non authentifiée dans son endpoint de build public. Le NVD lui attribue 9,8 (CVSS 3.1) ; la fiche CNA GitHub la note 9,3 (CVSS 4.0). Il est rare que l’un de ces scores soit le titre. Ici, le titre, c’est le chronomètre : la Threat Research Team de Sysdig a observé une exploitation dans la nature dans les 20 heures suivant l’avis, avant qu’aucun proof-of-concept public n’existe. Les attaquants ont lu l’avis, écrit l’exploit, et lancé leur scan de l’internet.

Cet article est une analyse défensive d’une vulnérabilité déjà divulguée et déjà corrigée. Aucun payload n’est reproduit — le correctif est public, la leçon est opérationnelle.

Comment ça marche

La faille réside dans un unique endpoint accessible sans authentification :

POST /api/v1/build_public_tmp/{flow_id}/flow

Dans les versions jusqu’à 1.8.1, cet endpoint accepte un paramètre optionnel data. Lorsqu’il est fourni, l’endpoint construit le flow à partir de données de flow contrôlées par l’attaquant au lieu de la définition stockée en base de données. Un « flow » Langflow est un graphe de nœuds, et les définitions de nœud peuvent porter du code Python. Ce chemin de code atteint exec() sans aucun bac à sable — le code de nœud fourni par l’attaquant s’exécute donc sur l’hôte avec les droits du processus Langflow.

Requête (non authentifiée)
  -> endpoint build_public_tmp
  -> `data` optionnel = graphe de flow de l'attaquant
  -> la définition de nœud contient du Python
  -> exec()  [pas de bac à sable]
  -> le code s'exécute sur l'hôte

Le correctif en 1.9.0 supprime purement et simplement le paramètre data de l’endpoint de build public, de sorte qu’on ne peut plus lui transmettre un graphe contrôlé par l’attaquant. Un détail importe : une version intermédiaire 1.8.2 a été présentée comme corrigée, mais JFrog Security Research a démontré que 1.8.2 restait exploitable et n’a pas pu identifier de correctif correspondant dans ses commits. En pratique, le numéro de version seul n’était pas un signal fiable de remédiation.

En phase de post-exploitation, des chercheurs ont rapporté des intrusions qui pivotaient directement vers la valeur : vol d’identifiants cloud (clés AWS) et déploiement de charges de type worker sur les hôtes compromis. L’endpoint donne l’exécution de code non authentifiée ; tout ce qui suit relève de la post-exploitation classique, selon ce que l’hôte Langflow peut atteindre.

Pourquoi c’est important

La première raison, c’est la fenêtre d’armement de 20 heures. Il n’y avait aucun PoC à copier. Le texte de l’avis a suffi à reconstruire le bug, et l’écart entre « divulgation » et « scan à l’échelle d’internet » est tombé sous la barre de la journée. Tout SLA de correctif qui suppose une semaine de calme après la sortie d’une CVE est calibré sur un modèle de menace qui ne tient plus pour les outils IA exposés sur internet.

La deuxième raison, c’est l’endroit où tourne ce logiciel. Langflow est un outil de construction — une commodité de développeur qui se retrouve fréquemment exposée sur une VM cloud avec un large accès sortant et des identifiants cloud ambiants, précisément parce que ce n’était « qu’un » outil de prototypage interne. C’est le pire hôte possible pour une RCE non authentifiée. La CISA a ajouté CVE-2026-33017 à son catalogue Known Exploited Vulnerabilities le 25 mars 2026, avec une échéance de remédiation au 8 avril pour les agences fédérales civiles au titre de la directive BOD 22-01 — le signe que cela touchait de vrais déploiements exposés, pas seulement des instances de laboratoire.

La troisième raison : exec() sur des données de graphe contrôlées par l’utilisateur est un schéma, pas un cas isolé. De nombreux frameworks d’orchestration LLM et de construction d’agents évaluent des « flows », « outils » ou « skills » fournis par l’utilisateur et porteurs de code. Si votre propre stack transforme une définition d’agent sérialisée en Python ou shell exécuté, vous possédez peut-être le même bug sous un autre nom. Le graphe de nœuds de Langflow n’en est que l’instance la plus visible.

Défenses

1. Passez en 1.9.0 ou supérieur — et vérifiez, ne faites pas confiance au numéro de version. Compte tenu du contournement de 1.8.2, confirmez que le paramètre data a bien disparu de build_public_tmp dans votre build en production, plutôt que de supposer qu’une release étiquetée « corrigée » l’est réellement.

2. Retirez Langflow de l’internet public. Un constructeur de flows n’a rien à faire en écoute sur 0.0.0.0 avec une IP routable. Liez-le à localhost, ou placez-le derrière un VPN / reverse proxy authentifié avec une ACL réseau. La plupart des instances exploitées étaient simplement accessibles.

3. Recalibrez les SLA de correctifs pour les outils IA exposés sur internet. Le chiffre des 20 heures est désormais votre nombre de planification. Traitez la publication de l’avis — et non la sortie du PoC — comme le départ du chronomètre d’exploitation, avec une voie d’urgence hors cycle pour les RCE non authentifiées sur les actifs exposés.

4. Supprimez les identifiants ambiants et limitez l’egress. Aucune clé AWS/cloud permanente sur l’hôte Langflow ; utilisez des accès IAM restreints et éphémères et un sortant par défaut interdit. Cela émousse le vol d’identifiants et le déploiement de worker observés en post-exploitation, même si l’exécution a lieu.

5. Éliminez exec()/eval() sur les définitions contrôlées par l’utilisateur dans vos propres constructeurs. Si les définitions d’agent/flow/skill peuvent porter du code, exécutez-les dans un bac à sable (processus séparé, seccomp, conteneur sans montages hôte ni réseau) — jamais en ligne dans le processus de l’orchestrateur.

6. Chassez les indicateurs. Alertez sur les requêtes vers build_public_tmp, sur les processus enfants anormaux engendrés par le processus Langflow, et sur les connexions sortantes inattendues (endpoints d’identifiants, brokers C2/worker inconnus). Inventoriez votre exposition avec un scan externe (Shodan/Censys) avant qu’un attaquant ne le fasse.

État des lieux

Élément	Référence	Date	Notes
Divulgation CVE-2026-33017	NVD / CNA GitHub	2026-03-17	RCE non authentifiée, CVSS 3.1 9,8 / CVSS 4.0 9,3
Exploitation dans la nature	Sysdig TRT	~2026-03-18	Dans les 20 heures suivant l’avis, sans PoC public
Ajout au CISA KEV	CISA / Help Net Security	2026-03-25	Échéance de remédiation FCEB 2026-04-08 (BOD 22-01)
Correctif	Langflow 1.9.0	2026	Supprime le paramètre data de build_public_tmp
1.8.2 encore exploitable	JFrog Security Research	2026	Release intermédiaire « corrigée » démontrée contournable

Le bug est corrigé. La leçon réutilisable ne concerne pas Langflow du tout : un constructeur non authentifié qui exécute du code fourni par l’utilisateur, laissé exposé sur internet, sera exploité à partir du texte de l’avis plus vite que la plupart des équipes ne peuvent planifier une fenêtre de correctif. Trouvez vos outils IA exposés et fermez-les avant que le prochain avis ne mette cette hypothèse à l’épreuve à votre place.