Retour au blog
CVEIA & LLMtechnique

LiteLLM CVE-2026-42271 : injection de commandes via les endpoints MCP, exploitée activement

Publié le 2026-07-066 min de lectureCleanIssue

> En bref : LiteLLM 1.74.2 à 1.83.6 permet à tout utilisateur authentifié du proxy d'exécuter des commandes arbitraires sur le serveur via deux endpoints de test MCP. CVSS 8.8, exploitation active confirmée par la CISA le 8 juin 2026. Correctif : 1.83.7.

Pourquoi ça vous concerne

LiteLLM est devenu la plomberie standard des fonctionnalités IA dans les SaaS : un proxy unique qui route vos appels vers OpenAI, Anthropic, Mistral ou vos modèles auto-hébergés, avec gestion des clés, des quotas et des coûts. Si votre produit a ajouté un assistant IA, un chat ou du parsing de CV par LLM ces deux dernières années, il y a une vraie probabilité qu'un proxy LiteLLM tourne quelque part dans votre infrastructure — parfois installé par un prestataire, parfois hérité d'un template.

C'est exactement ce genre de brique « invisible » qui fait les meilleures cibles.

La faille en deux phrases

LiteLLM expose des endpoints pour tester un serveur MCP avant de l'enregistrer : POST /mcp-rest/test/connection et POST /mcp-rest/test/tools/list. Ces endpoints acceptaient une configuration complète dans le corps de la requête — y compris les champs command, args et env utilisés par le transport stdio.

Autrement dit : vous envoyez une requête avec "command": "bash" et les arguments de votre choix, et le proxy exécute votre commande avec ses propres privilèges. Pas de désérialisation exotique, pas de chaîne d'exploitation complexe — l'endpoint fait exactement ce qu'on lui demande.

« Authentifié », donc pas grave ?

L'exploitation requiert une clé API du proxy. Beaucoup d'équipes s'arrêtent à ce mot et classent la faille comme mineure. C'est une erreur de lecture :

  • les clés LiteLLM sont souvent distribuées largement en interne (une par développeur, une par service, une par environnement) ;
  • elles traînent dans les fichiers .env, les historiques Git et les configurations de CI ;
  • une clé prévue pour *appeler un modèle* donne ici une *exécution de code sur le serveur* — une escalade massive entre le privilège accordé et le privilège obtenu.
  • La CISA a ajouté cette CVE à son catalogue KEV le 8 juin 2026 : elle est exploitée en conditions réelles, pas en théorie.

    Quoi faire, dans l'ordre

  • Vérifiez si LiteLLM tourne chez vous — y compris dans les projets annexes, les POC IA devenus production et les stacks montées par des prestataires. Red Hat OpenShift AI (2.25, 3.3, 3.4) embarque aussi les versions affectées.
  • Mettez à jour en 1.83.7 ou plus — le correctif restreint la configuration acceptée par les endpoints de test.
  • Faites tourner vos clés API du proxy — si la faille a pu être exploitée, les clés existantes doivent être considérées comme compromises.
  • Cherchez des traces : processus inhabituels lancés par le proxy, appels aux endpoints /mcp-rest/test/* dans vos logs.
  • Cloisonnez : le proxy LLM n'a aucune raison de tourner avec des privilèges larges ni sur la même machine que vos données clients.
  • La leçon qui dépasse LiteLLM

    Les surfaces MCP se multiplient dans les produits IA, et elles arrivent avec un pattern dangereux : des endpoints qui acceptent des *configurations exécutables* (commande, arguments, environnement) plutôt que des données. Chaque fois qu'un champ de requête finit dans un spawn(), vous avez un candidat RCE.

    Si votre SaaS a branché des fonctionnalités IA rapidement — assistant, RAG, parsing de documents — un audit de cette surface est devenu aussi urgent que celui de vos API classiques. Notre Premier diagnostic couvre les endpoints IA et MCP exposés : verdict en 48h.

    Articles liés

    Trois analyses proches pour continuer la lecture sur la meme surface de risque.

    Besoin d'une revue externe de votre SaaS RH ?

    Expliquez votre produit, votre stack et votre contexte client. Nous revenons vers vous avec le bon niveau de revue.

    Parler de votre audit