Aller au contenu
Kreomnis.Vigie
CVE-2026-42271Élevée8.7 KEV

LiteLLM : une injection de commande dans les endpoints MCP qui expose toutes vos clés LLM

Publiée le 15/06/2026// Kreomnis
CVSS 3.1
8.7
EPSS : probabilité d'exploitation
-
Source : FIRST.org, modèle EPSS v3
Produits/versions affectés
  • LiteLLM 1.74.2 à < 1.83.7
CISA KEV : exploitation observée

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/connection
  • POST /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 :

  1. l'attaquant s'authentifie avec n'importe quelle clé API valide (y compris une clé interne à faibles privilèges) ;
  2. il envoie une requête POST vers l'un des deux endpoints, avec un corps JSON décrivant un serveur MCP en transport stdio ;
  3. le champ command pointe vers un binaire arbitraire de l'hôte, args et env fournissent les paramètres contrôlés par l'attaquant ;
  4. 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

  1. 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"
  1. Mitigation immédiate si le patch ne peut pas être appliqué tout de suite : bloquer POST /mcp-rest/test/connection et POST /mcp-rest/test/tools/list au niveau du reverse proxy ou de l'API gateway.

  2. 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.

  3. 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/env et 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

Références

#litellm#mcp#command-injection#gateway-ia#rce