Les chercheurs de X41 D-Sec ont récemment dévoilé une faille critique nommée BadHost (CVE-2026-48710) affectant Starlette, le framework Python qui sert de fondation à des outils populaires tels que FastAPI, vLLM, LiteLLM, ainsi que de nombreux serveurs MCP fonctionnant sous FastAPI. Avec environ 325 millions de téléchargements chaque semaine, cette vulnérabilité illustre à quel point une seule injection malveillante dans le header HTTP “Host” peut compromette des déploiements en production. En injectant un simple caractère dans ce header, un attaquant peut contourner facilement les contrôles d’accès basés sur le chemin, mettant en danger des systèmes critiques déjà largement déployés.
Le proof of concept, publié par OSTIF, démontre la simplicité de l’exploitation. En modifiant le header “Host” en y ajoutant un point d’interrogation, il est possible de faire passer une requête qui normalement serait bloquée. Par exemple, la requête curl -i -H 'Host: foo?' http://target/admin renvoie un code 200, permettant ainsi d’accéder à des endpoints sensibles comme “/admin”. Cette faiblesse est d’autant plus problématique que Starlette reconstruit la propriété “request.url” en concaténant la valeur du header “Host” avec le reste du chemin, sans en valider le contenu, ce qui permet aux attaquants d’altérer la frontière entre le chemin, la requête et le fragment.
Les serveurs MCP exposés sont particulièrement vulnérables, car il s’agit souvent de coffres-forts contenant tokens, identifiants, accès à des bases de données, emails, services web, sans oublier des connexions à des ressources critiques comme S3 ou des webhooks. La faille menace donc gravement la sécurité de nombreux systèmes d’information en production.
Pour exploiter cette vulnérabilité, le processus est simple : il suffit d’envoyer une requête malformée utilisant certains caractères comme “/”, “?” ou “#” dans le header “Host”. Lorsque Starlette reconstruit “request.url”, ces caractères bouleversent la détection du chemin d’origine, permettant aux middlewares d’authentification de ne pas détecter la compromission. En conséquence, un endpoint qui doit être protégé peut être accessible sans contrôle, avec un score CVSS évalué à 7/10, une note que la société de cybersécurité Secwest estime sous-estimée compte tenu de la gravité potentielle de la faille.
La portée de cette vulnérabilité est alarmante : des bases de données de tests cliniques, des données personnelles en temps réel, des accès à des équipements industriels via SSH, ou encore des listes de souscripteurs et des topologies AWS entières ont été détectés dans des scans effectués par X41 D-Sec et OSTIF. La menace plane sur tout l’écosystème d’agents IA en production, qui semblent désormais vulnérables à une attaque pouvant ouvrir n’importe quel coffre-fort numérique. En réponse, il est impératif de mettre à jour Starlette vers la version 1.0.1 ou supérieure, en prenant soin de reconstruire les artefacts dans les images Docker, virtualenvs et autres environnements “vendorisés”. De plus, changer la méthode de lecture de “request.url.path” en la remplaçant par “request.scope[‘path’]” est recommandé pour renforcer la sécurité face à la réapparition du problème à l’avenir.
Concernant l’infrastructure, X41 D-Sec et OSTIF précisent que des serveurs comme nginx, Apache httpd ou Cloudflare filtraient déjà par défaut certains éléments du Proof of Concept, mais il demeure essentiel de tester minutieusement ses configurations avec le scanner Nemesis. La faille BadHost souligne également une problématique récurrente : la vulnérabilité de la chaîne d’approvisionnement de l’IA, souvent dépendante de mainteneurs bénévoles risquant leur engagement. La personne responsable du maintien de Starlette, Kludex, est actuellement submergée de rapports, et sans un effort collectif de soutien, de telles vulnérabilités risquent de rester dans l’ombre encore longtemps. La collaboration entre OSTIF, AWS et la communauté open source a permis de découvrir cette menace et d’y apporter une solution rapide, évitant ainsi une exploitation de masse potentiellement catastrophique.
En conclusion, si votre infrastructure exploite FastAPI, vLLM ou LiteLLM en production, deux actions immédiates s’imposent : d’une part, lancer une vérification avec le scanner Nemesis pour identifier d’éventuels vecteurs d’attaque, et d’autre part, contribuer financièrement ou moralement à la communauté qui maintient Starlette, notamment en soutenant Kludex. La sécurité de votre système dépend de votre réactivité face à cette faille critique, alors n’attendez pas pour vérifier et renforcer vos déploiements.
Sources : Ars Technica, OSTIF
