Injection de commandes MCP LiteLLM : CVE-2026-42271

GTIG confirme l’exploitation de CVE-2026-42271 : une clé LiteLLM valide pouvait lancer des commandes via l’aperçu MCP. Passez à 1.83.7+.^{[1], [6], [8]}

Vecteur CVSS

CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:H/VI:H/VA:H/SC:H/SI:N/SA:N^[1]

💡 Explication en Langage Simple (ELI5)

Un atelier laisse les visiteurs tester un outil avant de l’ajouter. Le comptoir d’essai peut démarrer une machine puissante de l’atelier ; seul un responsable devrait pouvoir lui donner des instructions. Dans les versions vulnérables de LiteLLM, toute carte acceptée donnait accès à ce comptoir. Une faille distincte de Starlette pouvait aussi tromper un gardien qui décide de l’accès à partir d’une URL reconstruite ; chaque frontière doit être corrigée séparément. À un autre comptoir, un visiteur peut inscrire une barre oblique ou un point d’interrogation sur l’étiquette d’un colis. L’employé recopie ce texte en reconstruisant l’adresse et le prend pour un nouvel itinéraire, alors que le colis suit toujours le couloir d’origine. C’est la confusion distincte entre Host et chemin dans Starlette.^{[1], [3], [5]}

Concepts Clés et Termes

Model Context Protocol (MCP): Protocole permettant à une application, par exemple une passerelle d’IA, de se connecter à des outils et à des sources de données externes. Les routes d’aperçu LiteLLM testent une configuration MCP avant son enregistrement.^[1]
Transport stdio: Mode MCP qui démarre un processus enfant local et échange des messages par l’entrée et la sortie standard. Le processus s’exécute sur l’hôte du proxy LiteLLM avec les privilèges du service.^{[1], [2]}
Autorisation par rôle: Contrôle côté serveur qui réserve une opération aux identités possédant le rôle exigé. CVE-2026-42271 avait laissé les routes d’aperçu sans le contrôle PROXY_ADMIN utilisé par l’opération d’enregistrement.^{[1], [2]}
CVE-2026-48710 (Starlette BadHost): Faille Starlette distincte : un en-tête Host invalide pouvait faire diverger request.url.path du chemin utilisé par le routage. Horizon3 a indiqué que cela pouvait contourner l’authentification par chemin de LiteLLM avec certaines dépendances ; ce n’est pas une partie de CVE-2026-42271.^{[3], [5], [4]}
Liste de commandes autorisées pour MCP stdio: Ensemble de noms de base d’exécutables acceptés par LiteLLM pour le transport stdio. Le contrôle intervient lors de la validation de configuration puis avant la création du client pour les anciennes entrées. Ce n’est pas un bac à sable, car les runtimes autorisés peuvent interpréter les arguments fournis.^[8]

Correspondances de référentiels

Référence CWE pour la faiblesse décrite dans ce guide : CWE-78
CISA KEV — ajouté le 2026-06-08 — CVE-2026-42271

Déroulement de l'Attaque Étape par Étape

Étape 1

Vérifier la version LiteLLM et l’exposition des routes

L’avis du mainteneur concerne LiteLLM >=1.74.2 et <1.83.7 et exige une clé API de proxy valide ; avant le correctif, tout détenteur authentifié, y compris avec une clé interne à faibles privilèges, pouvait accéder aux routes de prévisualisation. GTIG inclut CVE-2026-42271 dans sa liste d’exploitation confirmée ; pour les prérequis de ce CVE, retenez le modèle authentifié indiqué par l’avis du mainteneur.^{[1], [6]}

Étape 2

Une clé peu privilégiée atteint une action d’aperçu réservée aux administrateurs

Les routes acceptaient une configuration MCP complète, y compris la commande stdio, ses arguments et les variables d’environnement. Le serveur authentifiait la clé sans vérifier le rôle PROXY_ADMIN ; tout détenteur d’une clé authentifiée pouvait appeler l’aperçu.^[1]

Étape 3

L’aperçu démarre un processus sur l’hôte du proxy

Pour tester la configuration stdio reçue, LiteLLM créait un client MCP et lançait le processus enfant avec les privilèges du service proxy. Il s’agit d’une exécution de commandes sur l’hôte de la passerelle, pas seulement d’un texte dangereux généré par un modèle d’IA.^{[2], [8]}

Étape 4

Une faille Starlette distincte peut affaiblir la frontière d’authentification

Horizon3 a indiqué que CVE-2026-48710 pouvait faire voir à l’authentification par chemin un request.url.path différent de la route sélectionnée par Starlette lorsqu’une version vulnérable était présente. Les chercheurs ont signalé avoir chaîné ce comportement avec CVE-2026-42271 pour supprimer le prérequis de clé API dans certains déploiements. Attribuez cette chaîne aux chercheurs ; les deux CVE ont des causes et des correctifs distincts.^{[5], [3], [4]}

Étape 5

Corriger les deux frontières et vérifier les dépendances résolues

LiteLLM a corrigé les routes de prévisualisation dans la version 1.83.7 : elles exigent désormais PROXY_ADMIN et tools/list dispose d’une authentification explicite. Le correctif vérifie aussi la liste de commandes autorisées lors des créations/mises à jour, puis dans _create_mcp_client pour couvrir les anciennes configurations. Cette liste n’est pas un bac à sable ; les runtimes autorisés interprètent toujours leurs arguments. Starlette a corrigé séparément CVE-2026-48710 dans la version 1.0.1 ; vérifiez les versions résolues et évaluez séparément la chaîne signalée.^{[1], [8], [4], [7]}

Étape 6

Contexte de campagne récent (signalé le 7 octobre 2026)

Black Lotus Labs a indiqué qu’un échantillon du malware PoeLLM ciblait probablement /mcp-rest/test/connection ; BleepingComputer a également signalé des tentatives d’exploitation de CVE-2026-42271 dans cette campagne. Le rapport ne démontre ni que tous les hôtes infectés l’ont été via ce CVE, ni que toutes les cibles LiteLLM étaient vulnérables. Il s’agit d’un indice de ciblage actuel, pas d’un nombre de victimes attribuable à cette faille.^{[9], [10]}

Analyse de Cause Racine

La faille de LiteLLM provenait de l’absence de vérification du rôle sur les deux routes d’aperçu MCP : toute clé API valide du proxy pouvait les appeler sans le rôle PROXY_ADMIN. L’aperçu de connexion acceptait une configuration stdio fournie par le client et lançait sa commande avec les privilèges du processus proxy. Une faille distincte de Starlette permettait à un en-tête Host mal formé de faire diverger request.url.path du chemin routé par Starlette ; Horizon3 a indiqué que la validation de clé fondée sur le chemin pouvait être contournée en chaînant ce comportement avec LiteLLM. Il s’agit de vulnérabilités distinctes : corrigez les contrôles d’autorisation et d’exécution de commandes de LiteLLM, et mettez Starlette à jour vers la version 1.0.1 ou ultérieure.^{[1], [8], [3], [4], [5]}

Code Source : Vulnérable vs Sécurisé

Cet extrait reprend le correctif LiteLLM fusionné à la frontière d’exécution : il vérifie le nom de base de la commande avant de construire le client stdio, de sorte que les anciennes entrées en base/configuration passent aussi par le contrôle. Le correctif valide également les requêtes de création et de mise à jour des serveurs et réserve les deux points de prévisualisation à PROXY_ADMIN ; /test/tools/list reçoit aussi la dépendance explicite user_api_key_auth. La liste autorisée n’est pas un bac à sable : les runtimes autorisés peuvent toujours interpréter leurs arguments. Réservez la prévisualisation aux administrateurs et exécutez le proxy avec le minimum de privilèges.^{[1], [2], [8]}

Extrait source: Extrait de validation du client stdio LiteLLM

IMPLÉMENTATION VULNÉRABLE

# _create_mcp_client avant l’ajout du garde-fou sur les commandes stdio.
if server.command and server.args is not None:
    stdio_config = MCPStdioConfig(
        command=server.command,
        args=server.args,
        env=resolved_env,
    )

PATCH SÉCURISÉ ET ROBUSTE

# _create_mcp_client : revérifier les anciens enregistrements de base de données/configuration.
if server.command:
    base_command = os.path.basename(server.command)
    if base_command not in MCP_STDIO_ALLOWED_COMMANDS:
        raise HTTPException(
            status_code=403,
            detail="MCP stdio command is not in the allowlist",
        )

if server.command and server.args is not None:
    stdio_config = MCPStdioConfig(
        command=server.command,
        args=server.args,
        env=resolved_env,
    )

Liste de Contrôle de Sécurité pour l'Ingénierie

✓Inventoriez les déploiements du proxy LiteLLM et confirmez la version réellement résolue ; mettez les versions concernées à niveau vers 1.83.7 ou ultérieure.^{[1], [8]}
✓Inspectez le lockfile ou l’image déployée et confirmez Starlette 1.0.1 ou ultérieure si la version FastAPI résolue le permet ; ne forcez pas une dépendance sans tests.^{[3], [7]}
✓Avant la mise à niveau de LiteLLM, bloquez POST /mcp-rest/test/connection et POST /mcp-rest/test/tools/list au proxy inverse ou à la passerelle API, comme le recommande l’avis du mainteneur.^[1]
✓Vérifiez que les deux routes exigent user_api_key_auth et refusent tout rôle autre que PROXY_ADMIN avant de créer un client MCP.^{[1], [8]}
✓Ajoutez des tests montrant qu’une requête non authentifiée et une clé valide non administrative ne peuvent atteindre aucun aperçu, tandis qu’un administrateur autorisé peut utiliser le flux prévu.^[8]
✓Pour Starlette, testez le traitement des en-têtes Host mal formés et vérifiez que le middleware d’accès utilise le chemin ASGI canonique ou une URL validée par le framework.^{[3], [4]}
✓Examinez les journaux du proxy et la télémétrie des processus enfants pour repérer un usage inhabituel des routes d’aperçu ; faites tourner les identifiants conservés par le proxy si l’enquête suggère un accès plausible à l’hôte.^{[1], [8]}
✓Gardez les deux dossiers distincts : CVE-2026-42271 concerne l’exécution de commandes LiteLLM ; CVE-2026-48710 concerne l’analyse de Host et la confusion de chemin Starlette.^{[1], [3]}
✓Examinez LITELLM_MCP_STDIO_EXTRA_COMMANDS dans chaque environnement ; les entrées personnalisées élargissent le périmètre de confiance des exécutables sans sécuriser le traitement des arguments.^[8]

Sources

← AI Security Directory →