Comment une injection de commandes dans LiteLLM, combinée à une faille Starlette, crée une exécution de code à distance non authentifiée de criticité maximale

Les points de terminaison concernés sont :

• POST /mcp-rest/test/connection

• POST /mcp-rest/test/tools/list

Ces deux URL acceptent dans le corps de la requête JSON une configuration complète de serveur MCP, y compris les champs Cmd, args et env utilisés par le transport stdio pour lancer des processus serveur . Quand un utilisateur authentifié appelle l'un de ces points de terminaison, LiteLLM exécute la commande fournie comme un sous-processus sur la machine hôte, avec les mêmes privilèges que le processus du proxy LiteLLM lui-même .

À l'origine, BerriAI (l'éditeur de LiteLLM) avait divulgué cela comme une faille d'exécution de code à distance « authentifiée » : un attaquant avait besoin d'une clé API valide pour atteindre ces points de terminaison, sans autre vérification de rôle. N'importe quel utilisateur interne, même avec des privilèges faibles, pouvait exécuter des commandes arbitraires sur le serveur . Mais l'histoire ne s'arrête pas là.

La faille Starlette "BadHost" : le verrou de l'authentification sauté

La seconde vulnérabilité est CVE-2026-48710, surnommée « BadHost » par les chercheurs. Il s'agit d'une faille de validation de l'en-tête HTTP Host dans Starlette, le framework ASGI léger sur lequel reposent FastAPI, vLLM et des milliers d'autres applications web Python – dont LiteLLM . Toutes les versions de Starlette depuis la 0.8.3 jusqu'à la 1.0.0 sont concernées .

La cause racine est un désaccord d'interprétation entre la façon dont Starlette route les requêtes entrantes et celle dont il reconstruit l'URL pour la logique applicative . La couche de routage ASGI utilise le chemin HTTP brut pour décider quel point de terminaison est visé. Cependant, request.url – l'URL que voient le middleware et les décorateurs d'authentification – est reconstruite en concaténant l'en-tête Host brut avec le chemin de la requête, sans validation appropriée .

En injectant des caractères délimiteurs comme ? ou # dans l'en-tête Host, un attaquant peut rendre request.url.path complètement différent du chemin réellement routé . Le middleware voit un chemin inoffensif comme /, tandis que le routeur transmet la requête à la véritable cible en arrière-plan. N'importe quel middleware d'authentification basé sur le chemin et qui fait confiance à request.url.path peut ainsi être contourné sans effort .

L'enchaînement fatal : d'un score de 8.7 à 10.0

Le décorateur d'authentification de LiteLLM vérifie request.url.path pour déterminer si une requête a besoin d'une clé API valide. Le contournement BadHost permet à un attaquant de manipuler cette URL pour que le middleware voie un chemin qui ne nécessite pas d'authentification, tandis que le routeur ASGI envoie simultanément la requête vers l'un des points de terminaison vulnérables d'injection de commandes MCP .

Cela supprime le seul contrôle d'accès qui se dressait entre Internet et l'exécution de commandes arbitraires. Un attaquant sans le moindre identifiant ni accès préalable au réseau peut envoyer une seule requête HTTP spécialement conçue qui contourne entièrement l'authentification et exécute des commandes système sur l'hôte du proxy LiteLLM . Horizon3.ai a confirmé que la chaîne complète fonctionne et lui a attribué un score CVSS combiné de 10.0 – la sévérité maximale – car elle permet une exécution de code à distance sans authentification .

Les risques concrets pour votre système d'information

Une exploitation réussie donne à l'attaquant la possibilité d'exécuter des commandes avec les privilèges du processus du proxy LiteLLM. À partir de là, la surface de menace s'étend rapidement :

• Exécution de commandes arbitraires : L'attaquant peut installer des portes dérobées, des logiciels malveillants, des mineurs de cryptomonnaie, ou tout autre logiciel permis par le compte de service .
• Vol d'identifiants à grande échelle : Dans une architecture classique, le proxy LiteLLM sert d'intermédiaire entre les applications et des dizaines de fournisseurs de LLM. Il stocke les clés API pour OpenAI, Anthropic, Azure, AWS Bedrock, Google et d'autres services connectés dans sa base de données ou ses variables d'environnement . Exploiter cette vulnérabilité permet de dérober toutes ces clés en une seule opération.
• Déplacement latéral dans l'infrastructure IA : Avec des clés API cloud volées et un accès shell au serveur proxy, les attaquants peuvent rebondir vers les services connectés, les serveurs MCP internes, les bases de données vectorielles et les frameworks d'agents en aval .
• Implications plus larges sur l'écosystème : La faille BadHost de Starlette affecte plus de 400 000 projets dépendants, y compris des applications FastAPI, des serveurs vLLM, des déploiements de serveurs MCP et des frameworks d'agents IA. Tous ceux qui utilisent un middleware d'authentification basé sur le chemin avec une version de Starlette antérieure à la 1.0.1 sont exposés à ce même type de contournement .

Pourquoi l'alerte de la CISA est un signal d'urgence maximale

L'ajout de la CVE-2026-42271 au catalogue KEV par la CISA le 8 juin 2026 confirme que la vulnérabilité n'est pas théorique : des attaquants sont en train de l'exploiter activement . En vertu de la directive opérationnelle contraignante BOD 22-01, toutes les agences fédérales civiles américaines doivent appliquer les correctifs dans un délai imparti. La CISA recommande également vivement à toutes les organisations, publiques et privées, de traiter chaque ajout au catalogue KEV comme une priorité de correction d'urgence .

Le plan d'action immédiat pour les DSI et RSSI

La correction de l'exploit chaîné nécessite des mises à jour sur deux fronts, ainsi que plusieurs mesures de défense en profondeur pour traiter l'exposition des identifiants. Voici les étapes à suivre sans délai :

1. Mettre à jour LiteLLM. Passez à la version 1.83.7 ou ultérieure. Cette mise à jour supprime la capacité des points de terminaison de test MCP à exécuter directement des commandes fournies par l'utilisateur, fermant ainsi le vecteur d'injection .
2. Mettre à jour Starlette. Passez à la version 1.0.1 ou ultérieure. Le correctif valide les en-têtes Host entrants par rapport à la spécification des URL et ignore ceux contenant des caractères invalides, neutralisant la confusion de chemin qui permet le contournement d'authentification .
3. Révoquez immédiatement tous les identifiants stockés. Considérez que toute clé API, jeton d'accès ou identifiant de base de données que le proxy LiteLLM a pu conserver est compromis. Lancez sans attendre une rotation de toutes les clés (OpenAI, Anthropic, Azure, AWS...) et vérifiez les tableaux de bord de facturation à la recherche d'usages non autorisés .
4. Bloquez les points de terminaison au niveau du reverse proxy ou du WAF. Comme mesure de défense en profondeur pendant le déploiement des patchs, configurez votre reverse proxy (comme Nginx) ou votre pare-feu applicatif (WAF) pour rejeter toute requête vers

   POST /mcp-rest/test/connection

   et

   POST /mcp-rest/test/tools/list

   avant qu'elle n'atteigne l'application .
5. Auditez les logs a posteriori. Examinez les journaux du proxy LiteLLM à la recherche d'activités suspectes sur les points de terminaison de test MCP, en particulier les requêtes provenant d'adresses IP inconnues ou celles avec des en-têtes Host manipulés .

La sévérité combinée de 10.0, l'exploitation active dans la nature et la désignation KEV par la CISA signifient que les organisations exécutant des services basés sur LiteLLM ou Starlette doivent traiter ceci comme une intervention d'urgence de type « patcher et révoquer ». La fenêtre entre l'exploitation active et le vol d'identifiants est d'ores et déjà ouverte.