En janvier 2026, les chercheurs de X41 D-Sec auditaient le code source de vLLM dans le cadre d'un programme financé par l'Alpha-Omega Project via l'OSTIF. Ils ont découvert une faille d'authentification critique dans Starlette, le framework Python asynchrone qui constitue le socle de FastAPI, vLLM, LiteLLM, des serveurs MCP et de la quasi-totalité des agents IA déployés en production aujourd'hui.
La vulnérabilité a reçu l'identifiant CVE-2026-48710, surnommée BadHost. La divulgation a été coordonnée avec le mainteneur de Starlette, et le correctif a été publié simultanément à la révélation publique.
Plus de 400 000 projets référencés sur GitHub dépendent de Starlette. Ce chiffre suffit à mesurer l'ampleur potentielle du problème. Mais ce qui rend BadHost particulièrement préoccupant pour les équipes sécurité, c'est la nature de ce qu'elle expose : des passerelles API vers des modèles de langage, des proxies compatibles OpenAI, des orchestrateurs d'agents IA. Des composants qui, dans beaucoup d'organisations, ont été déployés rapidement, souvent sans durcissement réseau préalable.
Le cabinet Secwest estime que les scores CVSS officiels, 6,5 selon le mainteneur, 7,0 selon X41 D-Sec, sous-estiment substantiellement l'impact réel, notamment en raison de la chaîne de dépendances. Un attaquant qui contourne l'authentification sur un endpoint LiteLLM ou vLLM peut exécuter des requêtes arbitraires vers un modèle, exfiltrer des données contextuelles, ou pivoter vers d'autres composants internes. La surface d'attaque effective est donc bien plus large que ce que le score seul suggère.
Le problème prend racine dans la façon dont Starlette reconstruit l'URL d'une requête entrante. Le framework concatène l'en-tête HTTP Host avec le chemin de la requête, puis réanalyse l'URL ainsi formée. Ce qui manque dans ce processus : une validation de l'en-tête Host contre la grammaire définie par les RFC 9112 et RFC 3986, avant la reconstruction.
L'exploitation est directe. En injectant un caractère /, ? ou # dans l'en-tête Host, l'attaquant déplace la frontière du chemin dans l'URL reconstruite. Il en résulte une divergence entre request.url.path, la valeur que voient les middlewares et les logiques d'autorisation, et la route réellement traitée par le serveur ASGI. Tout contrôle d'accès basé sur le chemin de la requête devient alors inopérant.
Un seul caractère malformé dans l'en-tête suffit. Aucun compte valide, aucune interaction de la part d'un utilisateur légitime n'est nécessaire. L'attaque est silencieuse et ne laisse pas de trace évidente dans les logs applicatifs standards, ce qui complique la détection a posteriori via les indicateurs de compromission classiques.
Le correctif se trouve dans Starlette 1.0.1 : la bibliothèque valide désormais l'en-tête Host à la réception et rejette toute valeur malformée avant la reconstruction de l'URL.
Toute organisation qui fait tourner l'un des composants suivants dans une version antérieure à la correction est potentiellement exposée : FastAPI, LiteLLM, vLLM, des serveurs MCP, des passerelles API ou des proxies compatibles avec l'API OpenAI.
Les environnements les plus à risque sont ceux où ces services sont accessibles sans reverse proxy protecteur devant eux. C'est précisément la configuration la plus fréquente dans les contextes de recherche et développement IA : un service FastAPI ou vLLM monté rapidement pour des expérimentations internes, exposé sur un port direct, sans WAF ni validation d'en-tête en amont. Ces déploiements "temporaires" qui durent.
Les banques et organismes publics qui ont récemment intégré des outils IA conversationnels ou des agents automatisés dans leurs workflows méritent une attention immédiate. Même si ces services ne sont pas directement exposés sur Internet, un attaquant ayant accès au réseau interne, via un poste compromis, un accès VPN ou un prestataire tiers, peut exploiter BadHost sans privilège particulier.
Auditer l'inventaire des dépendances. Recenser tous les services Python qui utilisent Starlette, directement ou via FastAPI, LiteLLM, vLLM ou tout framework d'agent IA. Les manifestes requirements.txt, pyproject.toml et les images Docker sont les premiers endroits à inspecter. Un scan de composition logicielle (SCA) accélère cette étape sur des parcs importants.
Mettre à jour vers Starlette 1.0.1 immédiatement. C'est la seule correction fiable. Les versions antérieures restent vulnérables indépendamment de toute autre mesure. Tester la compatibilité dans un environnement de staging avant déploiement, puis valider avec l'outil mis à disposition sur badhost.org par les chercheurs.
Vérifier la présence d'un reverse proxy validant les en-têtes HTTP. Nginx, Caddy, HAProxy ou un WAF cloud positionnés devant les services ASGI peuvent filtrer les en-têtes Host malformés comme mesure de défense en profondeur. Cette couche ne remplace pas le correctif applicatif, mais réduit l'exposition dans l'intervalle.
Examiner les logs d'accès récents pour détecter des en-têtes Host anormaux. Rechercher des valeurs contenant des caractères /, ? ou # dans le champ Host. Ces patterns sont inhabituels dans du trafic légitime et peuvent signaler une tentative d'exploitation ou une reconnaissance préalable.
Inclure BadHost dans les briefings de sécurité pour les équipes IA et data. Les développeurs qui construisent ou maintiennent des services d'inférence ou d'orchestration d'agents doivent comprendre que l'authentification au niveau applicatif peut être contournée si Starlette n'est pas à jour. Ce n'est pas un problème de configuration, c'est une faille dans la bibliothèque elle-même.
Oui. Un attaquant disposant d'un accès réseau interne, via un poste compromis, un accès tiers ou un mouvement latéral, peut exploiter BadHost sans aucun identifiant. L'exposition sur Internet n'est pas un prérequis. La mise à jour vers Starlette 1.0.1 reste la seule réponse satisfaisante.
Oui. Secwest et X41 D-Sec estiment tous deux que ce score sous-évalue l'impact réel, en particulier dans les chaînes de dépendances IA. La facilité d'exploitation — un seul caractère malformé, sans authentification — et la sensibilité des composants exposés justifient un traitement prioritaire.
Les chercheurs ont mis en place un outil de test accessible sur badhost.org. Il permet de vérifier concrètement si un déploiement est affecté. En complément, vérifier la version de Starlette installée : toute version antérieure à 1.0.1 est vulnérable.
Tout proxy ou passerelle basé sur Starlette ou FastAPI l'est potentiellement. Cela inclut LiteLLM et les architectures similaires. Les proxies reposant sur d'autres stacks techniques ne sont pas directement affectés par cette CVE spécifique, mais méritent un audit séparé de leur gestion des en-têtes HTTP.
