LiteLLM Authentication Bypass
CVE-2026-49468
LiteLLM just disclosed CVE-2026-49468: an auth bypass via Host header injection, affecting every version before 1.84.0. If you run LiteLLM directly exposed to the internet, that’s a problem.
The mechanic is sneaky. LiteLLM’s auth layer asks Starlette what route is being requested. Starlette reconstructs the path using the Host header from the incoming HTTP request. FastAPI handles the actual routing. Those 2 components can be made to disagree about which endpoint you’re hitting. Manipulate the Host header, make Starlette think you’re on a public route while FastAPI hands you a sensitive management endpoint. No credentials needed.
CVSS v4: high. Network-based, zero auth required, zero user interaction. Attack complexity: low.
The saving grace: most deployments are probably fine. If LiteLLM sits behind a CDN, WAF, reverse proxy with strict server_name validation, or a cloud load balancer with host-based routing rules, the Host header gets validated upstream before it reaches LiteLLM. The attack needs an unfiltered header to land. (LiteLLM Cloud customers are also unaffected; the hosted environment handles this.)
Fix is version 1.84.0. No config changes required. If you can’t upgrade right now, put a WAF or reverse proxy in front of the instance.
LiteLLM is the plumbing for a lot of enterprise AI setups: it proxies calls to OpenAI, Anthropic, and others, manages API keys, logs usage, enforces spend limits. An auth bypass on the proxy hands an attacker that entire switchboard. Check your deployment topology and upgrade.
- Alex