LiteLLM Vulnerability Enables Authentication Bypass via Host Header

Reporting by GBHackers and CyberPress discloses a critical authentication bypass in LiteLLM, tracked as CVE-2026-49468 and registered under GHSA-4xpc-pv4p-pm3w. The flaw is located in litellm/proxy/auth/auth_utils.py within the get_request_route() function; the code derives the effective route from request.url.path, which the Starlette framework can reconstruct using the incoming HTTP Host header, the reports state. Because the authentication gate evaluates a route computed from attacker-controlled input, a crafted Host header can cause the auth layer to validate a different route than the one FastAPI dispatches, allowing unauthenticated access to management endpoints. CyberPress reports the CVSS vector as CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H. GBHackers and CyberPress both state the issue affects all LiteLLM versions before 1.84.0 and that the problem is patched in 1.84.0.

The concrete root cause reported is trusting request.url.path without validating its reconstruction source. Both sources describe how Starlette can use the Host header to rebuild the path, creating a mismatch between the path used by the authentication check and the path FastAPI later dispatches. The reports classify the weakness under CWE-290 (Authentication Bypass by Spoofing) and note the exploitability characteristics: network attack vector, low complexity, no required privileges, and no user interaction (as reflected in the CVSS vector reported by CyberPress).

Authentication bypasses in proxy or middleware layers are high-impact because they can expose administrative or management routes that were assumed protected. The reporting emphasizes that exposure depends on deployment topology: GBHackers and CyberPress note that upstream components which validate or normalize the Host header-CDNs, WAFs, reverse proxies with server_name allowlists, or host-based load balancers-can mitigate the issue. Both sources also state that LiteLLM Cloud customers are confirmed unaffected.

Observers should track adoption of the patched 1.84.0 release and whether downstream packaging/distributions propagate the fix. For practitioners, monitoring ingress and edge configurations that normalize the Host header and auditing any middleware that reconstructs request paths are reasonable steps based on the reported vulnerability mechanics. Public exploit reports or proof-of-concept code may appear rapidly given the vulnerability's low exploitation complexity; the two reports recommend prioritizing patching where direct exposure exists.