Quatre frameworks d’agents IA auto-hébergés exposaient une RCE non authentifiée
Le 20 octobre 2026, le NVD publie cinq CVE critiques — de 9,8 à 9,9 — sur les frameworks d’agents IA Letta, Langchain-Chatchat, DB-GPT et Piflow : des endpoints d’exécution d’outils sans authentification et des bases de données livrées avec des identifiants par défaut. Si vous déployez un de ces frameworks, coupez-le de l’Internet tant que vous n’avez pas vérifié la version et l’exposition des ports.
20 octobre 2026. Le NVD publie cinq CVE critiques — des scores de 9,8 à 9,9 — qui frappent les frameworks d’agents IA auto-hébergés Letta, Langchain-Chatchat, DB-GPT et Piflow. Même jour. Le point commun est structurel, pas accidentel : des endpoints qui exécutent des outils sans authentification et des bases de données livrées avec des mots de passe par défaut. Pourquoi c’est important : déployer l’un de ces frameworks tel quel, c’est exposer un shell root à quiconque atteint le port.
La classe de faille : l’exécution d’outils sans porte d’entrée
Un agent IA n’est pas qu’un modèle de langage. C’est un orchestrateur qui appelle des outils — un interpréteur Python, un shell, une base de données — pour accomplir une tâche. Le point de bascule tient en une question : qui est autorisé à déclencher ces outils, et à quelles conditions.
La vague publiée le 20 octobre 2026 montre que beaucoup de frameworks open source répondent à cette question par « personne, et aucune ». Les quatre cas partagent la même erreur de conception : l’endpoint qui exécute l’outil est exposé sans authentification, ou accorde à tout appelant le rôle admin par défaut.
Le résultat est toujours le même. Un attaquant distant envoie une requête unique, nomme l’outil shell ou exec_shell, et obtient l’exécution de commandes arbitraires en tant que root dans le conteneur — souvent avec, en prime, les clés API des modèles LLM en variables d’environnement.
Quatre frameworks, cinq CVE, un même schéma
Les cinq entrées se lisent comme une même fiche technique déclinée en quatre produits.
CVE-2026-77936 — Letta (≤ 0.16.8). Le fichier compose.yaml livré par défaut n’active pas la variable LETTA_SERVER_SECURE. Le middleware de mot de passe n’est donc jamais ajouté, toutes les routes API restent sans authentification, et le service expose un PostgreSQL en superutilisateur avec des identifiants par défaut. Conséquence : exécution de Python arbitraire via POST /v1/tools/run, gestion des utilisateurs via /v1/admin, et commandes système via COPY PROGRAM.
CVE-2026-75128 — Langchain-Chatchat (≤ 0.3.1.3). L’endpoint POST /tools/call invoque n’importe quel outil enregistré par son nom, sans authentification. L’outil shell, toujours enregistré, est donc appelable par quiconque : une requête suffit pour exécuter des commandes système en tant que root, puisque c’est l’utilisateur du conteneur dans l’image Docker livrée.
CVE-2026-77932 — DB-GPT (≤ 0.8.2). L’endpoint /api/v1/chat/react-agent s’appuie sur une fonction simulée get_user_from_headers qui accorde le rôle admin à chaque appelant. Un attaquant non authentifié peut alors envoyer des prompts qui font exécuter du Python ou du bash arbitraire par les outils code_interpreter et shell_interpreter de l’agent ReAct, en tant que root.
CVE-2026-77933 — DB-GPT (≤ 0.8.2). Le docker-compose.yml par défaut définit un MYSQL_ROOT_PASSWORD statique et publie le port 3306 sur toutes les interfaces. Un attaquant qui atteint ce port, ou le réseau interne partagé, s’authentifie en root@% avec tous les privilèges, y compris FILE et SUPER.
CVE-2026-109442 — Piflow (2.0.0 à 2.0.1). L’agent de chat DeepAgents expose POST /chat et POST /chat/stream sans authentification. Un attaquant demande à l’agent d’appeler l’outil exec_shell, qui exécute des commandes via subprocess.run sans approbation humaine ni liste blanche — et expose au passage les secrets d’environnement, dont les clés API LLM et les identifiants de base de données.
Ce que ce regroupement révèle
Le fait que cinq CVE d’un même type atterrissent le même jour n’est pas un hasard de calendrier : c’est la signature d’une catégorie en train de basculer. Le développement des agents IA a produit, en quelques mois, une génération de frameworks qui privilégient la démonstrabilité — « regardez, l’agent exécute du code » — au détriment de la frontière d’authentification.
Trois facteurs se cumulent. D’abord, l’exécution d’outils est la fonctionnalité centrale du produit, donc elle est exposée en premier et documentée en premier. Ensuite, ces outils sont par nature dangereux : un interpréteur Python ou un shell n’a pas de surface « lecture seule ». Enfin, les valeurs par défaut — compose.yaml, images Docker, mots de passe statiques — sont pensées pour un démarrage en une commande sur un poste de développeur, pas pour un déploiement exposé.
Le risque concret est celui du self-hosting. Ces frameworks sont précisément ceux qu’une équipe installe sur un VPS ou un NAS pour garder la main sur ses données et ses clés. La version auto-hébergée est supposée être la version sûre ; elle est ici la version vulnérable, parce que personne ne re-vérifie les valeurs par défaut avant de publier le port.
Ce qu’il faut faire maintenant
La remédiation est rapide à énoncer, plus lente à appliquer si l’instance est déjà en production.
- Vérifier la version. Passez à une version corrigée de chaque framework dès qu’elle est publiée. Pour Letta, activez
LETTA_SERVER_SECURE; pour DB-GPT, remplacez leMYSQL_ROOT_PASSWORDstatique et retirez la publication du port 3306. Ne vous contentez pas de croire que « la dernière image » est saine : les CVE couvrent des versions « jusqu’à » une borne, et la borne est récente. - Couper l’exposition. Si l’instance n’a pas de raison d’être joignable depuis l’Internet, placez-la derrière un VPN ou un reverse proxy authentifié. Un endpoint d’exécution d’outils ne doit jamais être la première chose que voit un scanner.
- Traiter le conteneur comme compromis. Une RCE non authentifiée signifie que vous devez supposer l’accès, pas seulement le corriger. Si l’instance a été exposée, pivotez les clés API LLM et les identifiants de base de données stockés dans l’environnement du conteneur, puis reconstruisez l’image à partir de zéro.
- Durcir le réseau par défaut. Ne publiez les ports de base de données que sur une interface interne, et refusez l’egress inutile. La moitié des failles ci-dessus exploite un port MySQL ou PostgreSQL que personne n’avait prévu d’exposer.
Verdict
Si vous auto-hébergez un framework d’agents IA, traitez-le comme un service à part entière : coupez l’exposition par défaut, activez l’authentification du middleware, remplacez les identifiants statiques et vérifiez la version avant de publier le moindre port. Si vous déployez de l’IA générative en équipe, retenez la leçon structurelle : l’endpoint d’exécution d’outils est la nouvelle surface critique de votre parc, et les valeurs par défaut des projets open source d’agents ne sont pas calibrées pour un déploiement exposé — c’est à vous de refermer la porte qu’ils laissent ouverte.