What happened
LiteLLM proxy versions prior to 1.84.0 contain a critical authentication bypass (CVSS 9.5, CWE-290) in the get_request_route() function inside litellm/proxy/auth/auth_utils.py. The auth layer derives the effective route from request.url.path, which the Starlette framework reconstructs from the attacker-controlled HTTP Host header. A crafted Host header causes the authentication gate to evaluate a different route than FastAPI dispatches, granting unauthenticated access to protected management endpoints such as /key/generate and /user/new. Discovered by Le The Thang (KCSC) and Kim Ngoc Chung (One Mount Group); fixed in 1.84.0. Note: CVE-2026-49468 was previously flagged in the 2026-06-21 digest; this entry is confirmed fresh via full-text Phase 2 verification from multiple independent sources.
Why it matters
LiteLLM is one of the most widely deployed open-source LLM API gateways, sitting as a central chokepoint for dozens of LLM provider API keys. A successful exploit gives an attacker full administrative control: they can steal downstream API keys, mint new access tokens, and reconfigure routing — effectively compromising every LLM workload behind the proxy. Deployments directly exposed to the internet without an upstream CDN/WAF are fully vulnerable without authentication.
Attack vector
Remote unauthenticated HTTP request with a crafted Host header to the LiteLLM proxy listener. Exploitable only when the proxy is exposed directly (no upstream CDN/WAF/reverse-proxy with strict server_name validation).
Affected systems
LiteLLM (BerriAI) < 1.84.0
Mitigation
Upgrade to LiteLLM ≥ 1.84.0 (pip install --upgrade 'litellm>=1.84.0'). If immediate patching is not possible, place the proxy behind an upstream component (NGINX, CDN, WAF) that validates and normalises the Host header. GHSA: https://github.com/advisories/GHSA-4xpc-pv4p-pm3w