LiteLLM : une injection de commande dans les endpoints MCP qui expose toutes vos clés LLM
- LiteLLM 1.74.2 à < 1.83.7
Cette vulnérabilité est inscrite au catalogue des vulnérabilités activement exploitées de la CISA. Traitement prioritaire recommandé.
Le contexte
LiteLLM est une passerelle LLM (AI Gateway) très répandue : elle expose en format compatible OpenAI une myriade de fournisseurs (OpenAI, Anthropic, Mistral, Azure...) derrière un point d'entrée unique. C'est exactement le genre de composant qu'on déploie pour mutualiser et gouverner l'accès aux modèles : et exactement le genre de composant dont la compromission fait très mal.
CVE-2026-42271 est une injection de commande (CVSS 8.7, HIGH) dans deux endpoints preview du serveur MCP de LiteLLM. Elle a été ajoutée au catalogue CISA KEV après confirmation d'une exploitation active, et CISA a alerté publiquement début juin 2026. Horizon3.ai a démontré une chaîne d'exploitation non authentifiée jusqu'à la RCE.
La mécanique
Les deux endpoints en cause sont :
POST /mcp-rest/test/connectionPOST /mcp-rest/test/tools/list
Ils acceptaient une configuration serveur MCP complète, y compris les champs command, args et env du transport stdio. À l'appel, LiteLLM lançait cette entrée comme sous-processus sur l'hôte de la passerelle, avec les privilèges du processus proxy et sans aucune validation ni sandbox.
Le déroulé d'attaque :
- l'attaquant s'authentifie avec n'importe quelle clé API valide (y compris une clé interne à faibles privilèges) ;
- il envoie une requête
POSTvers l'un des deux endpoints, avec un corps JSON décrivant un serveur MCP en transport stdio ; - le champ
commandpointe vers un binaire arbitraire de l'hôte,argsetenvfournissent les paramètres contrôlés par l'attaquant ; - le proxy exécute le processus : l'attaquant obtient l'exécution de commande avec les privilèges du proxy.
La chaîne qui supprime même le prérequis d'authentification
Horizon3.ai a chaîné CVE-2026-42271 avec CVE-2026-48710 (une bascule de validation du header Host, dite « BadHost », côté Starlette) pour contourner totalement l'authentification et obtenir une RCE non authentifiée contre les déploiements LiteLLM vulnérables.
L'angle qui fait mal
LiteLLM est une passerelle centrale. Une seule instance compromise expose simultanément les clés API de tous les fournisseurs connectés. Là où une fuite classique compromet un secret, ici on parle du trousseau complet d'une organisation pour ses accès LLM : OpenAI, Anthropic, Mistral et le reste. C'est précisément le débat de l'hygiène des gateways IA souveraines : centraliser l'accès aux modèles a du sens, mais le point de centralisation devient une cible de très haute valeur.
Versions impactées
| Produit | Version | Statut | | --- | --- | --- | | LiteLLM | 1.74.2 à < 1.83.7 | Vulnérable | | LiteLLM | 1.83.7 et ultérieures | Corrigée | | Starlette (chaîne BadHost) | < 1.0.1 | Vulnérable (CVE-2026-48710) |
Comment patcher
- Mettre à jour LiteLLM vers ≥ 1.83.7 et Starlette vers ≥ 1.0.1 (pour neutraliser la chaîne d'auth bypass).
pip install --upgrade "litellm>=1.83.7" "starlette>=1.0.1"
-
Mitigation immédiate si le patch ne peut pas être appliqué tout de suite : bloquer
POST /mcp-rest/test/connectionetPOST /mcp-rest/test/tools/listau niveau du reverse proxy ou de l'API gateway. -
Rotation des secrets : si l'instance a pu être exposée, considérer les clés API de tous les fournisseurs connectés comme compromises et les renouveler.
-
Durcissement : ne pas exposer les endpoints d'administration / preview de la passerelle, cloisonner le processus proxy (utilisateur dédié, droits minimaux), surveiller la création de sous-processus inattendus.
PoC
Horizon3.ai a publié l'analyse de la chaîne d'exploitation (CVE-2026-42271 + CVE-2026-48710). L'exploitation in-the-wild étant confirmée par CISA, considérer toute instance exposée comme une cible active. Lier vers la recherche originale, ne pas ré-héberger d'exploit.
Ce qu'il faut retenir
Un endpoint « preview » qui accepte une config
command/args/envet la lance en sous-processus, c'est une porte d'exécution déguisée en fonction de test. Sur une passerelle LLM, l'enjeu n'est pas un serveur, mais toutes les clés des fournisseurs.
Pour les RSSI et équipes plateforme IA :
-
Patch immédiat (KEV) : LiteLLM ≥ 1.83.7 et Starlette ≥ 1.0.1.
-
Traitez la gateway IA comme un coffre : accès admin/preview jamais exposés, clés cloisonnées par fournisseur et par usage, rotation possible en un clic.
-
Surveillez l'exécution : toute création de sous-processus par le proxy LLM est anormale et doit lever une alerte.
-
Kreomnis