LiteLLM: Authentication Bypass via Host Header Injection
Description
LiteLLM proxy before v1.84.0 allows authentication bypass via crafted Host header leading to route mismatch, granting unauthenticated access to protected management routes under specific conditions.
AI Insight
LLM-synthesized narrative grounded in this CVE's description and references.
LiteLLM proxy before v1.84.0 allows authentication bypass via crafted Host header leading to route mismatch, granting unauthenticated access to protected management routes under specific conditions.
Vulnerability
A Host-header parsing flaw in the LiteLLM proxy, in litellm/proxy/auth/auth_utils.py::get_request_route(), allows a mismatch between the route evaluated by the authentication layer and the route dispatched by FastAPI. Starlette reconstructs request.url.path from the Host header, so a crafted Host can cause the auth gate to evaluate a different route. This affects versions before 1.84.0 [1][2][3].
Exploitation
An attacker must be able to send HTTP requests directly to the proxy listener without an upstream component that validates or normalizes the Host header. By providing a malicious Host header, the attacker can cause the auth layer to see a benign route while FastAPI dispatches to a protected management route, bypassing authentication [2][3].
Impact
Successful exploitation results in unauthenticated access to protected management routes, potentially leading to information disclosure or unauthorized actions. The impact is limited to deployments that do not have validating upstream layers such as CDN, WAF, reverse proxy with server_name allowlists, or host-based load balancers. LiteLLM Cloud customers are not affected [2][3].
Mitigation
Fixed in version 1.84.0 [1]. Upgrade to 1.84.0 or later; no configuration change required. If immediate upgrade is not possible, place the proxy behind an upstream component that validates or normalizes the Host header before forwarding, or restrict network access to the proxy listener [2][3].
AI Insight generated on Jun 16, 2026. Synthesized from this CVE's description and the cited reference URLs; citations are validated against the source bundle.
Affected products
1Patches
0No patches discovered yet.
Vulnerability mechanics
Root cause
"The auth layer derives the effective route from `request.url.path`, which Starlette reconstructs from the attacker-controlled `Host` header, creating a mismatch with the route FastAPI actually dispatches."
Attack vector
An attacker sends an HTTP request with a crafted `Host` header to the LiteLLM proxy. The auth layer in `litellm/proxy/auth/auth_utils.py::get_request_route()` reads `request.url.path`, which Starlette reconstructs from the `Host` header rather than the actual dispatched route. This discrepancy lets the attacker make the auth gate evaluate a different (less restricted) route than the one FastAPI actually dispatches, bypassing authentication for protected management endpoints. The attack is only viable when no upstream component (CDN, reverse proxy, load balancer) validates or normalizes the `Host` header before it reaches the proxy.
What the fix does
The patch in release v1.84.0 addresses the root cause by ensuring the effective route used for authentication is derived from the actual dispatched path rather than from `request.url.path`, which Starlette reconstructs from the attacker-controlled `Host` header. No configuration change is required after upgrading. The fix closes the discrepancy between the route the auth gate evaluates and the route FastAPI dispatches, preventing a crafted `Host` header from bypassing authentication.
Preconditions
- configNo upstream component (CDN, WAF, reverse proxy, load balancer) that validates or normalizes the Host header
- networkNetwork access to the LiteLLM proxy listener
- inputAbility to send HTTP requests with a crafted Host header
Generated on Jun 16, 2026. Inputs: CWE entries + fix-commit diffs from this CVE's patches. Citations validated against bundle.
References
3News mentions
0No linked articles in our index yet.