"BadHost : la vulnérabilité Starlette qui a exposé des millions d'agents IA et de serveurs MCP"

"BadHost : la vulnérabilité Starlette qui a exposé des millions d'agents IA et de serveurs MCP"
📑 Table of Contents

BadHost : La vulnérabilité Starlette qui a exposé des millions d’agents IA et de serveurs MCP

28 mai 2026 — Une vulnérabilité critique de contournement d’authentification dans Starlette, le framework ASGI Python qui sous-tend une grande partie de l’écosystème d’infrastructure IA, a exposé des millions d’agents IA et de serveurs MCP (Model Context Protocol) à des risques de vol de données, d’exposition d’identifiants et d’exécution de code à distance.

Identifiée sous la référence CVE-2026-48710 et surnommée BadHost, cette vulnérabilité permet à des attaquants de contourner les intergiciels d’authentification basés sur le chemin avec un seul caractère malformé dans l’en-tête HTTP Host. Le défaut affecte toutes les versions de Starlette antérieures à la 1.0.1, publiée vendredi.

« Des millions d’agents IA et d’outils dans le monde ont été mis en danger par une vulnérabilité critique qui permet à des pirates de pénétrer les serveurs qui les exécutent et de dérober des données sensibles et des identifiants », a rapporté Dan Goodin d’Ars Technica dans un article.

Comment fonctionne BadHost

Starlette reconstruit request.url en concaténant l’en-tête HTTP Host avec le chemin de la requête — sans valider la valeur Host par rapport à la grammaire RFC 9112 ou RFC 3986. Un attaquant peut envoyer un en-tête conçu comme Host: example.com/health?x= qui décale les limites du chemin et de la requête lors du ré-analyse, faisant pointer request.url.path vers un point de terminaison différent de celui que le serveur ASGI a réellement routé.

Le résultat : le routeur dispatch sur le chemin réel du fil (par exemple /admin), mais l’intergiciel voit le chemin empoisonné ré-analysé (par exemple /health). Toute décision de sécurité basée sur le chemin prise dans l’intergiciel peut être contournée.

X41 D-Sec, la société de sécurité qui a découvert le bogue lors d’un audit sponsorisé par OSTIF, l’a décrit en termes clairs :

« Un seul caractère injecté dans l’en-tête HTTP Host contourne l’autorisation basée sur le chemin dans Starlette, le cœur de routage de FastAPI. »

L’ampleur : des millions de systèmes affectés

Starlette reçoit 325 millions de téléchargements par semaine et constitue le fondement de FastAPI — le framework web Python le plus populaire pour les applications IA. L’impact en aval est stupéfiant :

  • vLLM — où le bogue a été initialement découvert — le principal serveur d’inférence LLM open-source
  • LiteLLM — le proxy LLM largement utilisé qui se place devant des dizaines de fournisseurs de modèles
  • Serveurs MCP — l’infrastructure Model Context Protocol qui connecte les agents IA à des outils externes, bases de données et API
  • Harnais d’agents et tableaux de bord d’évaluation
  • Google ADK-Python et Ray Serve
  • BentoML et autres plateformes de déploiement ML

Les serveurs MCP sont particulièrement exposés car la spécification MCP impose des points de terminaison de découverte OAuth non authentifiés, offrant aux attaquants un chemin fiable pour trouver et exploiter les instances vulnérables. Ces serveurs stockent des identifiants pour des bases de données, comptes email, services cloud et outils internes — ce qui en fait des cibles exceptionnellement précieuses.

Types de données exposées par les scans

Le scan à l’échelle d’Internet réalisé par X41 D-Sec a révélé une gamme inquiétante de données exposées sur les systèmes vulnérables :

Secteur Données exposées
IA biopharmaceutique Bases de données d’essais cliniques, données de fusions-acquisitions
Vérification d’identité Analyse faciale, KYB, PII en direct, bases de code internes
IoT/Industriel Accès SSH aux appareils, exécution de code à distance
Email/SaaS Accès complet à la boîte mail (lecture/envoi/suppression), exports S3
RH/Recrutement PII des candidats, données du pipeline de recrutement
Surveillance cloud Topologie AWS, requêtes de métriques
Cybersécurité Inventaire des actifs, accès au scanner en direct

Pourquoi cela importe pour les agents IA

La vulnérabilité BadHost est emblématique d’un risque structurel dans l’écosystème des agents IA : la confiance au mauvais niveau. Starlette, FastAPI, vLLM et LiteLLM forment l’épine dorsale de la plupart des infrastructures IA basées sur Python, mais l’interaction entre le comportement du serveur ASGI, la construction d’URL du framework et les décisions d’authentification de l’intergiciel a créé une vulnérabilité qu’aucun composant seul ne pouvait corriger.

Comme l’a noté OSTIF dans sa divulgation : « Ce bogue est un “fossé de responsabilité” classique : si ce mainteneur n’avait pas corrigé, des milliers de projets exposés auraient dû sécuriser individuellement leurs projets. »

La vulnérabilité met également en lumière une limitation des outils de sécurité actuels basés sur l’IA. Les chercheurs ont noté que même Claude Mythos (l’agent de scan de code d’Anthropic) n’a pas trouvé CVE-2026-48710 lors du projet Glasswing, car le bogue s’étend sur trois couches indépendantes — chacune se comportant correctement isolément — plutôt que d’exister dans une seule base de code.

Atténuation et réponse

La correction : Mettez à jour Starlette vers la version 1.0.1 ou ultérieure. La version corrigée rejette les en-têtes Host contenant des caractères invalides au lieu de les utiliser pour la construction d’URL.

Pour ceux qui ne peuvent pas mettre à jour immédiatement :

  1. Remplacez request.url.path par request.scope["path"] dans chaque intergiciel, dépendance et décorateur qui prend des décisions de sécurité
  2. Déployez un proxy inverse conforme aux RFC (nginx, Caddy, Traefik, HAProxy) qui valide les en-têtes Host avant de les transmettre aux serveurs ASGI
  3. Auditez les versions groupées et intégrées de Starlette — les images conteneur, les environnements virtuels et les dépendances installées via pip peuvent épingler des versions vulnérables

Un scanner en ligne gratuit est disponible sur badhost.org — développé conjointement par X41 D-Sec, Persistent Security Industries et Bintech — pour vérifier si un point de terminaison accessible est vulnérable. Le dépôt open-source comprend également des preuves de concept (PoC), des règles Semgrep pour la détection statique et des requêtes CodeQL pour le scan à grande échelle.

Le message à retenir

Pour les développeurs qui construisent sur l’infrastructure des agents IA, BadHost est un signal d’alarme. L’écosystème des outils IA Python a connu une croissance si rapide que les hypothèses de sécurité fondamentales au niveau du framework sont restées inexplorées. Toute équipe exploitant des serveurs MCP basés sur FastAPI, des proxys LLM ou des harnais d’agents doit traiter cela comme une priorité critique — scanner son infrastructure, corriger Starlette et auditer les intergiciels pour les modèles d’authentification basés sur le chemin.

La vulnérabilité a peut-être été divulguée, mais l’impact réel dépend de la rapidité avec laquelle l’écosystème applique les correctifs. Avec 325 millions de téléchargements hebdomadaires et des serveurs MCP contenant des identifiants pour des systèmes de production, la fenêtre d’exploitation est grande ouverte.

Sources : Ars Technica — Millions of AI agents imperiled by critical vulnerability | OSTIF — Disclosing the BADHOST Vulnerability | badhost.org — Scanner & Details | OSV — CVE-2026-48710