Une faille dans Starlette permet de contourner l'authentification sur toute app FastAPI utilisant une auth basée sur le chemin

Les chercheurs en sécurité de X41 D-Sec, dans le cadre d'un audit OSTIF du framework d'inférence vLLM, ont découvert une faille critique de contournement d'authentification dans Starlette — le framework ASGI Python qui sous-tend FastAPI et un vaste écosystème d'infrastructure d'agents IA. Identifiée comme CVE-2026-48710 et baptisée BadHost, la faille permet à un attaquant de manipuler l'en-tête HTTP Host pour faire rapporter à Starlette un chemin d'URL différent de celui réellement routé par le serveur web — contournant tout middleware qui utilise request.url.path pour les décisions de contrôle d'accès. Le correctif est disponible dans Starlette 1.0.1.

L'impact est vaste. Starlette compte plus de 400 000 dépendants sur GitHub et plus de 325 millions de téléchargements hebdomadaires sur PyPI. Les applications concernées incluent tout ce qui est construit avec FastAPI utilisant un middleware d'authentification basé sur le chemin, ainsi qu'un ensemble spécifique d'outils d'infrastructure IA : vLLM, LiteLLM, les serveurs Model Context Protocol (MCP), FastMCP, ADK-Python de Google, Ray Serve et BentoML sont tous vulnérables lorsque un middleware d'authentification personnalisé est en place.

Comment fonctionne l'attaque

Les requêtes HTTP incluent un en-tête Host qui identifie le domaine cible. Starlette construit son objet request.url en concaténant l'en-tête Host brut avec le chemin de la requête, puis réanalyse la chaîne combinée en un objet URL. Le problème : Starlette ne validait pas que l'en-tête Host respecte la grammaire RFC 9112 avant de l'utiliser dans cette construction. Un attaquant peut injecter des caractères séparateurs de chemin — /, ? ou # — dans l'en-tête Host, ce qui décale ce que l'analyseur voit comme chemin, requête et fragment lorsqu'il réanalyse l'URL assemblée.

Le résultat est une vue divisée : le serveur ASGI route la requête vers le chemin réel (par exemple, /admin), mais request.url.path — ce que lit le middleware d'authentification — rapporte le chemin contrôlé par l'attaquant à la place (/health, ou tout autre chemin bénin que le middleware laisserait passer). L'avis X41 inclut une preuve de concept aussi simple que :

curl -H 'Host: foo?' localhost:8000/admin

Sur un serveur vulnérable avec une auth basée sur le chemin, cela renvoie 200 OK depuis l'endpoint protégé /admin plutôt qu'un 403 Forbidden.

La raison pour laquelle la vulnérabilité est restée si longtemps non détectée est qu'elle émerge de l'interaction de trois couches qui semblent chacune raisonnables isolément : les serveurs ASGI transmettent l'en-tête Host brut sans validation ; Starlette lui fait confiance pour la construction de l'URL ; et les développeurs de middleware supposent que request.url.path est une valeur sûre et faisant autorité côté serveur pour le contrôle d'accès. Aucune couche prise individuellement n'est défaillante.

Qui est concerné

La vulnérabilité est surtout importante pour les applications qui restreignent l'accès à des endpoints protégés via un middleware qui vérifie le chemin de la requête. C'est un motif courant dans les applications FastAPI où un préfixe de chemin (comme /admin, /internal ou /v1/private) détermine l'autorisation. Les applications qui utilisent les décorateurs Depends() ou Security() intégrés de FastAPI au niveau de chaque route ne sont généralement pas affectées, car ces mécanismes vérifient l'autorisation au moment de la résolution de la route plutôt que par inspection du chemin dans un middleware.

L'impact sur l'infrastructure IA est la préoccupation la plus aiguë. Les serveurs MCP — qui implémentent le Model Context Protocol pour connecter les agents IA à des outils et sources de données — sont particulièrement exposés car la spécification MCP impose des endpoints de découverte OAuth non authentifiés, offrant aux attaquants un chemin de contournement fiable connu sans avoir à deviner quels chemins sont non protégés. vLLM et LiteLLM, largement utilisés pour servir et proxyer des grands modèles de langage en production, sont affectés lorsqu'ils sont derrière un middleware d'authentification basé sur Starlette. ADK-Python de Google, le SDK Python pour construire des agents IA avec les modèles de Google, fait également partie de la liste des affectés.

Remédiation

Le correctif principal consiste à mettre à niveau vers Starlette 1.0.1, qui rejette les en-têtes Host contenant des caractères invalides au lieu de les utiliser pour la construction d'URL. Pour les applications qui ne peuvent pas mettre à niveau immédiatement, l'atténuation consiste à remplacer toute utilisation de request.url.path dans le middleware d'authentification ou d'autorisation par scope["path"] — le chemin de scope ASGI, qui vient directement de la ligne de requête HTTP et n'est pas influencé par l'en-tête Host. La recommandation à long terme est d'éviter complètement l'authentification basée sur le chemin dans le middleware en faveur des mécanismes Depends() et Security() au niveau des routes de FastAPI.

L'équipe de recherche a publié des outils de détection parallèlement à la divulgation : des règles Semgrep, des requêtes CodeQL pour l'analyse statique, et un scanner gratuit sur badhost.org qui peut tester directement les endpoints. Le scanner prend en charge trois modes — spécifique MCP, découverte automatique d'infrastructure IA, et test de chemin personnalisé — afin que les équipes puissent évaluer l'exposition sans lire l'avis complet.

CVE-2026-48710 a été découverte le 27 janvier 2026 et coordonnée pour divulgation publique les 21-22 mai 2026, après le correctif Starlette 1.0.1. Tous les détails techniques se trouvent dans l'avis X41 sur x41-dsec.de.