Rapport CTI technique du 5 août 2026
Résumé exécutif
CISA a ajouté le 4 août 2026 la CVE-2026-9198 à son catalogue Known Exploited Vulnerabilities, aux côtés d'une faille N-able N-central et d'une faille Apache Tomcat. La vulnérabilité touche IBM Langflow OSS, un framework open source très utilisé pour construire des workflows d'agents LLM, dans les versions 1.0.0 à 1.10.0. Elle combine deux défauts déjà connus séparément dans l'écosystème Langflow : un endpoint d'auto-connexion qui délivre un jeton SUPERUSER à n'importe quel appelant réseau, et un endpoint de validation de code qui exécute ce code via exec() sans sandboxing. Chaînés, ces deux points donnent à un attaquant non authentifié une exécution de code arbitraire sur le serveur, avec les privilèges du process Langflow.
Le cas est intéressant au-delà du bug lui-même : Langflow accumule les CVE RCE depuis 2025 (CVE-2025-3248, CVE-2026-8476, CVE-2026-8481, CVE-2026-8505, CVE-2026-9135, CVE-2026-33017), presque toutes liées au même choix d'architecture consistant à évaluer du code utilisateur côté serveur pour construire des graphes de traitement. Pour un pentester, Langflow exposé sur Internet doit désormais être traité comme une surface d'attaque a priori compromise plutôt que comme un outil interne inoffensif, surtout quand AUTO_LOGIN tourne encore avec sa valeur par défaut.
Chronologie
| Date | Événement |
|---|---|
| 2026-07-17 | Publication de CVE-2026-9198 dans la base NVD |
| 2026-07-24 | Dernière mise à jour de la fiche NVD |
| 2026-08-04 | CISA ajoute CVE-2026-9198 au catalogue KEV, sur preuve d'exploitation active, avec CVE-2026-18556 (N-able N-central) et CVE-2026-34486 (Apache Tomcat) |
| 2026-08-05 | Publication de ce rapport |
Fiche vulnérabilité
CVE-2026-9198 | CVSS 9.8 (Critical, vecteur 3.1 : AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H) | IBM Langflow OSS, versions 1.0.0 à 1.10.0
La route /api/v1/auto_login a été conçue pour accélérer le développement local en délivrant automatiquement un jeton de session SUPERUSER. Dans le déploiement par défaut, ce comportement n'est conditionné ni par l'origine réseau, ni par un mode mono-utilisateur explicite, ni par un flag de configuration dédié : tout appelant capable d'atteindre le listener HTTP reçoit un jeton pleinement privilégié. L'attaquant présente ensuite ce jeton à /api/v1/validate/code, un endpoint qui accepte du code source Python et le passe à exec() pour "valider" la syntaxe d'un composant. exec() s'exécute dans le process serveur, donc valider revient à exécuter. La faille est classée CWE-94 (Improper Control of Generation of Code).
Conditions d'exploitation : accès réseau à l'API HTTP de Langflow, aucune authentification préalable, aucune interaction utilisateur. L'attaque se résume à deux requêtes HTTP successives : un GET ou POST sur /api/v1/auto_login pour obtenir le JWT, puis un POST sur /api/v1/validate/code avec le payload Python. PoC disponible : aucun PoC public confirmé spécifiquement pour CVE-2026-9198 au moment de la rédaction, contrairement à sa cousine CVE-2026-33017 (endpoint /api/v1/build_public_tmp, faille distincte du même projet) qui dispose de plusieurs PoC publiés sur GitHub. Patch/mitigation : mise à jour vers une version postérieure à 1.10.0 selon les indications de la page de support IBM ; en attendant, désactivation explicite de l'auto-login (LANGFLOW_AUTO_LOGIN=false avec des identifiants SUPERUSER définis manuellement) et retrait de toute exposition directe à Internet.
Diagramme de la chaîne d'attaque
Chaîne reconstruite à partir des avis SentinelOne, IBM Support et de la fiche NVD.
Analyse technique
Étape 1 : reconnaissance de l'instance exposée
Un attaquant scanne les plages IP à la recherche du port par défaut de Langflow (7860) ou identifie l'instance via des bannières HTTP caractéristiques de l'API FastAPI de Langflow. Aucune authentification n'est requise pour cette phase, une simple requête GET sur la racine ou sur /api/v1/auto_login suffit à confirmer la présence du service et son mode de configuration.
Étape 2 : obtention d'un jeton SUPERUSER
L'attaquant envoie une requête vers /api/v1/auto_login. En configuration par défaut, la route ne vérifie ni l'origine de la requête ni un état mono-utilisateur, elle renvoie systématiquement un jeton JWT associé au rôle SUPERUSER. Ce comportement, hérité d'un choix de confort pour le développement local, devient une porte d'entrée directe dès que l'instance est joignable depuis un réseau non fiable.
Étape 3 : exécution de code via l'endpoint de validation
Muni du jeton, l'attaquant construit un payload JSON contenant du code Python et le soumet à /api/v1/validate/code. La fonction serveur qui traite cette route appelle exec() sur le contenu reçu pour vérifier sa syntaxe et son exécutabilité dans le cadre de la construction d'un composant Langflow. Il n'existe pas de sandboxing AST-only à cette étape, le code tourne directement dans l'interpréteur du process serveur.
Étape 4 : post-exploitation dans le contexte du service
Une fois le code exécuté, l'attaquant dispose des privilèges du compte de service Langflow. Cela permet la lecture de fichiers arbitraires, l'écriture sur le système de fichiers, l'exfiltration des secrets stockés dans les flows (clés API de fournisseurs de modèles, identifiants de bases de données, jetons cloud), et l'établissement d'un canal de sortie vers une infrastructure contrôlée par l'attaquant pour maintenir l'accès.
Indicateurs de compromission
| Type | Valeur |
|---|---|
| Endpoint ciblé | /api/v1/auto_login suivi de /api/v1/validate/code depuis la même IP source |
| Motif réseau | Requêtes séquentielles vers ces deux routes en moins de quelques secondes, hors plage d'adresses de développement connue |
| Payload | Corps JSON de /api/v1/validate/code contenant import os, import subprocess, import socket, ou du code Python encodé en base64 |
| Processus enfant | sh, bash, curl, wget, python -c lancés par le process Python de Langflow |
| Réseau sortant | Connexions initiées par le process Langflow vers des hôtes non répertoriés, immédiatement après un appel à validate/code |
Aucune liste d'infrastructures ou d'adresses IP attaquantes n'a été publiée par CISA ou par les éditeurs au moment de la rédaction. Les indicateurs ci-dessus sont comportementaux, à surveiller côté journalisation applicative et EDR.
MITRE ATT&CK
Aucune cartographie officielle CISA ou vendeur n'a été publiée pour cette CVE au moment de la rédaction. Le tableau suivant est une lecture technique construite à partir du déroulé de l'exploitation, pas une attribution vendeur.
| Tactique | Technique | ID | Justification |
|---|---|---|---|
| Initial Access | Exploit Public-Facing Application | T1190 | L'attaquant atteint directement l'API HTTP exposée de Langflow sans authentification préalable |
| Privilege Escalation | Valid Accounts | T1078 | Le jeton SUPERUSER obtenu via auto_login donne d'emblée les privilèges les plus élevés de l'application |
| Execution | Command and Scripting Interpreter: Python | T1059.006 | Le payload soumis à validate/code s'exécute comme du Python natif via exec() |
| Credential Access | Unsecured Credentials: Credentials In Files | T1552.001 | Les clés API et identifiants stockés dans les définitions de flows deviennent accessibles une fois l'exécution de code obtenue |
| Exfiltration | Exfiltration Over C2 Channel | T1041 | Les secrets récupérés peuvent être renvoyés vers l'infrastructure de l'attaquant via le canal établi lors de la post-exploitation |
Remédiation : checklist opérationnelle
- Recenser toutes les instances Langflow exposées, en interne comme en externe, et vérifier leur version exacte via l'endpoint de version ou les métadonnées du conteneur.
- Mettre à jour vers une version postérieure à 1.10.0 en suivant la page de support IBM, puis redéployer les conteneurs avec l'image mise à jour plutôt que de patcher en place.
- Désactiver LANGFLOW_AUTO_LOGIN et configurer explicitement LANGFLOW_SUPERUSER avec un mot de passe fort et unique.
- Retirer toute exposition directe à Internet : placer Langflow derrière un reverse proxy authentifiant ou un VPN, et lier le listener à 127.0.0.1 quand l'accès distant n'est pas nécessaire.
- Faire tourner le service sous un compte non privilégié dans un conteneur avec filtrage de sortie, pour limiter l'impact d'une exécution de code malgré tout.
- Vérifier après mise à jour que /api/v1/auto_login ne délivre plus de jeton à un appelant non authentifié.
- Faire tourner toutes les clés API, identifiants de bases de données et jetons cloud stockés dans des flows sur les hôtes potentiellement exposés avant le correctif.
- Rechercher des signes d'exploitation antérieure : nouvelles entrées cron, clés SSH ajoutées, connexions sortantes inhabituelles dans les logs du process Langflow.
- Ajouter une règle de détection sur la séquence auto_login puis validate/code depuis une même source dans le SIEM ou l'outil de corrélation de logs.
