Selon des experts de la société X4 D-Sec, un seul caractère mal formé dans une requête web peut suffire pour qu’un attaquant non authentifié parvienne à contourner les contrôles d'accès qui protègent les applications construites sur Starlette, le framework Python open source qui alimente FastAPI (pour la création d'API en Python). La faille, référencée CVE-2026-48710, pourrait permettre aux cybercriminels de contourner les protections de validation d'hôte en utilisant des en-têtes Host mal formés. « L'attaquant n'a besoin ni de mot de passe ni d'action de la part de la victime », a précisé l’entreprise de cybersécurité. Après la divulgation de la vulnérabilité par X41 D-Sec, en coordination avec l'Open Source Technology Improvement Fund (Ostif), le responsable de Starlette a publié un correctif via un avis de sécurité officiel sur GitHub.

La vulnérabilité a été découverte lors d'un audit du code source sans rapport avec cette affaire, et attribuée par les chercheurs à Starlette plutôt qu'à l'application en cours d'examen. « Ce bug est un cas classique de « hiatus dans la chaîne de responsabilité » : si ce responsable n’avait pas publié de correctif, des milliers de projets exposés auraient dû être sécurisés individuellement », a déclaré l’Ostif. Il est possible de tester la vulnérabilité des sites web sur le site badhost.org créé par les chercheurs.

Exploitation du bug

Selon X41 D-Sec, la faille réside dans la manière dont Starlette reconstitue l'adresse d'une requête entrante. Le framework associe l'en-tête Host envoyé par le client au chemin demandé pour former une URL complète, mais vérifie la validité de l'ensemble et de ses différentes parties en appliquant des règles différentes. « Un en-tête Host contenant une barre oblique, un point d'interrogation ou un caractère dièse déplace le point de départ du chemin, de sorte que le chemin signalé par Starlette ne correspond plus à celui que le serveur a réellement reçu », ont expliqué les chercheurs.

Selon la société, c'est dans cet écart que réside le risque. Starlette achemine la requête vers le chemin réel, mais le middleware et les terminaux lisent celui qui a été modifié. Les chercheurs ont envoyé une requête vers une page d'administration protégée et ont reçu une réponse « 403 Forbidden ». Ils ont envoyé la même requête avec un caractère supplémentaire dans l'en-tête Host, et la page a renvoyé un « 200 OK ». Le même schéma est apparu dans d'autres failles récentes de contournement d'authentification dans des frameworks d'IA open source.

Contestations sur le degré de gravité

Dans l’avis publié sur GitHub, le responsable de Starlette a évalué la faille à 6,5 sur 10, ce qui correspond à un niveau de gravité « modéré » sur l’échelle CVSS. X41 D-Sec lui a attribué un score de 7, c'est-à-dire « élevé », estimant que le danger pour les logiciels basés sur Starlette était plus important que ne le suggèrent ces deux scores. L'ampleur des dégâts qu'un attaquant peut causer dépend de la manière dont chaque application traite le chemin d'accès falsifié. X41 D-Sec a identifié plusieurs projets open source dont les contrôles de sécurité s'appuient sur l'adresse reconstruite. Dans ces projets, cette faille d'un seul caractère pourrait entraîner « un contournement de l'authentification et évoluer jusqu’à une falsification des requêtes côté serveur (Server-side request forgery, SSRF), et d'autres problèmes peuvent dans certains cas aller jusqu'à l'exécution de code à distance sur le système affecté », ont écrit les chercheurs.

La portée de cette faille s'étend bien au-delà de Starlette lui-même. Un avis distinct de l’entreprise de sécurité Secwest à propos de cette faille indique que le score « sous-estime considérablement l'impact en aval » et elle prévient que le bug touche « la plupart des infrastructures de serveurs de modèles, de passerelles, de proxys, d'évaluation, d'agents et de serveurs Model Context Protocol (MCP) mises en place au cours des deux dernières années ». Selon X41 D-Sec et Secwest, les logiciels affectés comprennent les outils de service de modèles, les passerelles API, les proxys compatibles OpenAI, les frameworks d’agents et les serveurs Model Context Protocol basés sur FastAPI. « Une application peut être exposée même si ses développeurs n’ont jamais installé Starlette, car un autre composant pourrait l’avoir fait », a mis en garde X41 D-Sec qui précise que « Starlette compte plus de 400 000 projets dépendants sur GitHub ».

Une exposition variable

« Tous les projets dépendants ne sont pas exposés au même risque », a également souligné la société. La vulnérabilité d'une application dépend de sa configuration. La différence réside dans le proxy inverse : un proxy tel que nginx ou Apache HTTP Server rejette les requêtes mal formées avant qu'elles n'atteignent l'application, et les sites web en production sont généralement protégés par une telle couche. « Ce n'est souvent pas le cas des environnements de recherche, d'évaluation et de développement pour les logiciels IA, et beaucoup font fonctionner le serveur d'applications directement connecté au réseau », a ajouté l’entreprise.

Selon X41 D-Sec, trois groupes sont les plus exposés : ceux qui exécutent une application FastAPI ou Starlette directement sur un serveur d'applications sans proxy inverse conforme en amont ; ceux qui exposent un proxy de modèle tel que LiteLLM ou vLLM en tant que point de terminaison directement accessible ; et ceux dont le code de contrôle d'accès lit l'adresse de la requête reconstruite plutôt que le chemin brut. Les chercheurs ont conseillé aux équipes de passer à Starlette 1.0.1 ou une version ultérieure, qui valide l'en-tête Host et rejette les valeurs mal formées.