Les endpoints de test MCP de LiteLLM : une injection de commandes désormais activement exploitée

De quoi s’agit-il ?

LiteLLM est l’une des passerelles IA open source les plus déployées : un proxy qui offre aux consommateurs IA internes une interface unique compatible OpenAI devant plus d’une centaine de fournisseurs de modèles. Une faille d’injection de commandes de sévérité élevée, située dans ses endpoints de test Model Context Protocol (MCP), permet à tout détenteur d’une clé API du proxy d’exécuter des commandes arbitraires sur l’hôte de la passerelle. LiteLLM a publié le correctif dans la version 1.83.7 le 8 mai 2026 ; toutes les versions de 1.74.2 à 1.83.6 sont affectées.

Ce qui distingue cette vulnérabilité du flot habituel de CVE, c’est sa chronologie. Le 8 juin 2026, la CISA l’a ajoutée à son catalogue Known Exploited Vulnerabilities (KEV) après avoir confirmé une exploitation active — soit environ cinq semaines après le correctif. L’AI Safety Initiative de la Cloud Security Alliance a publié une note de recherche détaillée le 13 juin 2026, et la presse spécialisée a signalé une activité d’exploitation démarrant peu après l’avis. Il s’agit donc d’une vulnérabilité corrigée et publiquement divulguée, actuellement exploitée contre les passerelles non mises à jour.

Comment ça marche

La faille se trouve dans deux endpoints ajoutés pour prendre en charge l’intégration MCP de LiteLLM : POST /mcp-rest/test/connection et POST /mcp-rest/test/tools/list. Ils devaient permettre à un opérateur de prévisualiser un serveur MCP avant de l’enregistrer, et acceptent donc une configuration de serveur complète directement dans le corps de la requête — reflétant le transport stdio de MCP, avec les champs command, args et env qui décrivent un sous-processus à lancer sur l’hôte du proxy.

La cause racine combine deux omissions : aucun contrôle d’autorisation (les endpoints n’étaient pas réservés à un rôle administratif) et aucun traitement sécurisé de la configuration de processus fournie par l’appelant (pas de liste d’autorisation de commandes, pas de sandbox). Tout principal disposant d’une clé API valide du proxy — un identifiant couramment distribué aux équipes de développement et aux services automatisés simplement pour accéder aux modèles — pouvait donc amener le proxy à exécuter une commande fournie. La faille isolée est notée CVSS 8.7 ; seule l’exigence de clé API l’a maintenue hors du niveau critique.

Cette exigence disparaît lorsque la faille est chaînée. Des chercheurs de Horizon3.ai ont démontré sa combinaison avec la faille de contournement d’authentification BadHost dans Starlette — une désynchronisation de l’en-tête Host qui casse l’autorisation basée sur le chemin dans les services fondés sur FastAPI. Un en-tête Host forgé passe outre le middleware, et la requête atteint l’endpoint MCP vulnérable sans aucun identifiant, produisant une exécution de code à distance non authentifiée notée CVSS 10.0.

Aucune chaîne d’exploitation n’est reproduite ici ; le mécanisme décrit ci-dessus provient entièrement des avis publics.

Pourquoi c’est important

Les passerelles IA occupent une position structurellement privilégiée. Un déploiement LiteLLM de production détient généralement les clés API de chaque fournisseur qu’il dessert, les identifiants de la base de données de journalisation des usages, et la configuration de politique qui contrôle quelles équipes accèdent à quels modèles. L’exécution de code sur cet hôte ne s’arrête donc pas à la passerelle : elle expose toute la surface de credentials concentrée derrière elle, et dans les déploiements Kubernetes, un compte de service aux permissions trop larges peut étendre la portée jusqu’au plan de contrôle du cluster.

La leçon plus large est un schéma, pas un bug isolé. Des fonctionnalités de confort — un endpoint « tester ce serveur MCP » en ligne — ont été livrées sans les contrôles d’autorisation adaptés à un composant qui centralise tout le trafic IA. C’est la même classe de défaillance qui a produit d’autres problèmes LiteLLM cette année, dont une injection SQL pré-authentification dans le proxy. Le middleware IA est désormais une cible de premier ordre, et mérite une posture de sécurité comparable à celle des systèmes de gestion des identités et des accès plutôt qu’à celle d’un outil interne de développement.

Défenses

Mettez à jour immédiatement. Passez LiteLLM en 1.83.7 ou ultérieure, qui réserve les endpoints de test MCP au rôle PROXY_ADMIN, et mettez à jour Starlette en 1.0.1 dans le même cycle. Sans la mise à jour de Starlette, la chaîne non authentifiée reste exploitable même face à un code LiteLLM corrigé.

Réduisez l’exposition si vous ne pouvez pas corriger aujourd’hui. Supprimez l’accès Internet public au proxy et limitez sa joignabilité aux seuls services qui en ont réellement besoin. Cela élimine à soi seul la voie externe non authentifiée pendant que vous planifiez la mise à jour.

Faites tourner et réduisez les credentials. Traitez toute passerelle ayant exécuté une version vulnérable comme potentiellement compromise : renouvelez chaque clé API fournisseur détenue par le proxy, et révoquez les clés API du proxy distribuées à des utilisateurs ou services sans besoin actif. Moins de détenteurs de clés, c’est moins de principaux capables de déclencher la faille même sans le contournement d’en-tête Host.

Chassez les compromissions. Recherchez les processus inattendus lancés par le compte de service LiteLLM, les nouveaux fichiers dans les répertoires cron ou systemd, les connexions sortantes inhabituelles depuis l’hôte du proxy, et les modifications inexpliquées des variables d’environnement ou de la base de données LiteLLM.

Corrigez la classe, pas seulement la CVE. Imposez un contrôle d’accès basé sur les rôles à chaque opération administrative plutôt qu’un modèle de clé API à plat, isolez le middleware IA sur son propre plan réseau, et auditez l’écosystème Starlette au sens large — services FastAPI, serveurs vLLM, frameworks MCP — pour le même contournement d’en-tête Host, indépendamment de toute exposition directe à LiteLLM.

Statut

Élément	Référence	Date	Notes
Injection de commandes isolée	CVE-2026-42271 (NVD)	divulguée en 2026	CVSS 8.7 ; endpoints de test MCP, toute clé API du proxy
Version corrigée	LiteLLM 1.83.7	2026-05-08	Endpoints réservés à PROXY_ADMIN ; Starlette porté à 1.0.1
RCE non authentifiée chaînée	avec CVE-2026-48710 (BadHost)	2026	CVSS 10.0 ; contournement d’authentification par en-tête Host dans Starlette
Ajout au KEV de la CISA	Catalogue KEV de la CISA	2026-06-08	Exploitation active confirmée
Note de recherche CSA	Cloud Security Alliance	2026-06-13	Analyse de la surface de credentials des passerelles IA
Versions affectées	LiteLLM 1.74.2 → 1.83.6	—	Mettre à jour en 1.83.7+

À retenir pour les équipes techniques : une passerelle IA concentre les credentials de tout ce qu’elle dessert, donc un endpoint de confort placé dessus n’est jamais anodin. Mettez à jour vers 1.83.7 et Starlette 1.0.1, retirez le proxy d’Internet, renouvelez les clés qu’il détenait, et traitez le middleware IA avec la même rigueur que vos systèmes d’identité.