CVE-2026-49468: 
LiteLLM Schwachstellenanalyse und -minderung

CVE-2026-49468 is an authentication bypass vulnerability in the LiteLLM proxy caused by a Host header parsing flaw, allowing unauthenticated attackers to access protected management routes under specific conditions. It affects all LiteLLM versions prior to 1.84.0 (pip package litellm). The vulnerability was first published to the GitHub Advisory Database on May 28, 2026, and updated on June 16, 2026. It carries a CVSS v4.0 base score of 9.5 (Critical) (GitHub Advisory).

The root cause is classified as CWE-290 (Authentication Bypass by Spoofing). The authentication layer in litellm/proxy/auth/auth_utils.py::get_request_route() derives the effective route from request.url.path, which Starlette reconstructs from the HTTP Host header. By crafting a malicious Host header value, an attacker can cause the auth gate to evaluate a different route than the one FastAPI actually dispatched, effectively bypassing authentication checks for protected management endpoints. No privileges or user interaction are required, though the attack requires specific deployment conditions — namely, the absence of any upstream layer (CDN, WAF, or reverse proxy) that validates or normalizes the Host header (GitHub Advisory, LiteLLM Advisory).

Successful exploitation allows an unauthenticated remote attacker to access protected management routes on the LiteLLM proxy, resulting in high impact to confidentiality, integrity, and availability of both the vulnerable system and subsequent systems. An attacker could read sensitive configuration data (including API keys for downstream LLM providers), modify proxy settings, or disrupt service availability. The broad scope of subsequent system impact reflects the risk of lateral movement to connected AI/LLM backends and infrastructure (GitHub Advisory).

1. Reconnaissance: Identify internet-facing LiteLLM proxy instances running versions prior to 1.84.0 that lack an upstream CDN, WAF, or reverse proxy enforcing Host header validation.
2. Identify protected management routes: Review LiteLLM documentation or source code to enumerate management API endpoints (e.g., /key/generate, /model/new, /user/new) that are normally restricted to authenticated users.
3. Craft malicious Host header: Construct an HTTP request with a Host header value that, when parsed by Starlette to reconstruct request.url.path, resolves to a public or unauthenticated route rather than the actual management route being targeted.
4. Send crafted request: Submit the HTTP request directly to the LiteLLM proxy listener, targeting a protected management endpoint while the manipulated Host header causes get_request_route() to evaluate the request as if it were destined for an unprotected route.
5. Achieve unauthorized access: The auth gate, deceived by the spoofed route evaluation, permits the request without authentication, granting the attacker access to management functionality such as API key creation, model configuration changes, or user management (GitHub Advisory, LiteLLM Advisory).

• Network: Unexpected HTTP requests to LiteLLM management endpoints (e.g., /key/generate, /model/new, /user/new) originating from unauthenticated or unknown sources; requests containing anomalous or non-standard Host header values that do not match the configured proxy hostname.
• Logs: LiteLLM proxy access logs showing successful (2xx) responses to management routes without corresponding authentication tokens or API keys; repeated requests to admin endpoints from the same source IP with varying Host header values.
• Application Behavior: Unexpected creation of new API keys, users, or model configurations in the LiteLLM admin panel; unauthorized changes to proxy routing or model settings not attributable to known administrators.

Upgrade the litellm pip package to version 1.84.0 or later — no configuration change is required after upgrading (GitHub Advisory, LiteLLM v1.84.0 Release). If immediate upgrading is not possible, place the LiteLLM proxy behind an upstream component that validates or normalizes the Host header, such as a CDN or WAF (e.g., Cloudflare), a reverse proxy configured with explicit server_name allowlists (e.g., nginx), or a cloud load balancer with host-based routing rules. As an additional measure, restrict network access to the proxy listener to trusted sources only. LiteLLM Cloud customers are not affected and require no action.

The vulnerability received coverage from multiple security news outlets shortly after the advisory was published, including GBHackers, CyberPress, CyberSecurityNews, and IT Security News, all highlighting the authentication bypass risk via Host header injection (GBHackers, CyberSecurityNews). The vulnerability was discovered by Le The Thang (KCSC) and Kim Ngoc Chung (One Mount Group), who are credited in the official advisory. Community discussion noted that most production deployments are protected by standard infrastructure layers, limiting the practical attack surface (GitHub Advisory).