LiteLLM proxy authentication bypass via Host header injection

Undisclosed·LiteLLM proxy (self-hosted deployments)Fixed

The LiteLLM proxy's auth layer derived the effective route from request.url.path via get_request_route(), which Starlette reconstructs from the Host header; an attacker could send a crafted Host header so the auth check evaluated a different route than the one FastAPI actually dispatched, letting them reach protected management routes without authenticating.

Blast radius

Unauthenticated access to protected LiteLLM proxy management routes on affected self-hosted deployments (versions before 1.84.0); LiteLLM states most deployments were not affected because a CDN/WAF, reverse proxy with server_name allowlists, or host-based load balancer in front of the proxy blocks the bypass, and LiteLLM Cloud customers were not affected. No specific victim organisation or exploitation-in-the-wild is disclosed.

Root cause

Auth gate re-derived the request route from a Host-header-influenced URL reconstruction (request.url.path) instead of trusting the route FastAPI actually dispatched, allowing route confusion between the authorization check and the handled request.

How it was caught

Found and reported by external security researchers (Le The Thang of KCSC and Kim Ngoc Chung of One Mount Group) rather than through in-production monitoring or an attack being observed.

What changed

Patched in LiteLLM 1.84.0 (no configuration change required); interim workaround was to place the proxy behind an upstream component that validates/normalizes the Host header or to restrict network access to the proxy listener.

Take-awayDon't let an authorization decision be computed from a header-derived, attacker-influenced URL reconstruction that can diverge from the route the web framework actually dispatches — authorize against the resolved route object, not a re-parsed path.