# LiteLLM Proxy Authentication Bypass via Host Header Injection (CVE-2026-49468)

> A critical authentication bypass (CWE-290, CVSS 4.0 9.5) in the LiteLLM proxy lets an unauthenticated, network attacker inject a crafted HTTP Host header so the auth layer evaluates a different route than the one FastAPI actually dispatches, exposing protected management endpoints. Rooted in the Starlette 'BadHost' class (CVE-2026-48710) and fixed in LiteLLM 1.84.0.

- **Published:** 2026-06-17T00:00:00Z
- **Last reviewed:** 2026-06-17T00:00:00Z
- **Canonical:** https://intel.threadlinqs.com/threat/TL-2026-0833
- **ID:** TL-2026-0833
- **Severity:** CRITICAL (CVSS 9.5)
- **Category:** VULNERABILITY
- **Status:** ACTIVE
- **Detections:** 9 · **IOCs:** 17 (full data via the Threadlinqs MCP server — Purple tier)
- **CVEs:** CVE-2026-49468, CVE-2026-42271, CVE-2026-48710

## Description

CVE-2026-49468 is an authentication bypass by spoofing in the LiteLLM proxy server (BerriAI/litellm), a widely deployed open-source LLM gateway. LiteLLM's authentication layer determines which route an incoming request targets by reading request.url.path inside litellm/proxy/auth/auth_utils.py::get_request_route(). Starlette reconstructs request.url.path by concatenating the scheme, the client-supplied Host header value, and the request path, and it never validates that the Host header contains a syntactically valid hostname. By injecting a single special character (?, /, or #) into the Host header, an attacker shifts the URL parsing boundaries: for example, a Host value ending in '?' causes Starlette to assemble a URL such as http://foo?/admin, so request.url.path is parsed as empty (or a different value) while the FastAPI/Starlette router still dispatches to the real endpoint using the raw ASGI scope['path']. The authentication middleware therefore evaluates and authorizes a route that does not match the route actually executed, permitting unauthenticated access to sensitive administrative/management endpoints (key management, user and team administration, model and credential management).

The attack vector is network, attack complexity is low, no privileges and no user interaction are required (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 = 9.5). The 'AT:P' (attack requirements: present) reflects that exploitation depends on the proxy being reachable without an upstream component that normalizes or validates the Host header; deployments fronted by a CDN, WAF, host-validating reverse proxy, or load balancer are generally not exploitable, and LiteLLM Cloud customers are not affected.

This flaw is one instance of the broader 'BadHost' vulnerability class affecting the Starlette ASGI framework and its dependents (FastAPI, vLLM, LiteLLM, the Python MCP SDK, Text Generation Inference, Ray Serve, BentoML, Google ADK-Python). The root cause is tracked upstream as CVE-2026-48710 (Starlette, CVSS 6.5; X41 assessed downstream impact at 7.0) and was fixed in starlette>=1.0.1. In LiteLLM specifically, the path-confusion bypass can be chained with other LiteLLM weaknesses; public reporting documents CVE-2026-42271 (LiteLLM) chained with the Starlette host-header bypass (CVE-2026-48710) to achieve unauthenticated remote code execution against AI gateways, with active exploitation reported for that chain. CVE-2026-49468 itself had no public PoC or confirmed in-the-wild exploitation attributed to it at disclosure, but the management-endpoint exposure it provides (virtual API keys, model and team configuration, cached credentials) makes it a high-value foothold for credential theft and downstream model/resource abuse.

Remediation is to upgrade to LiteLLM 1.84.0 or later (no configuration change required), and/or place the proxy behind infrastructure that validates and normalizes the Host header. The structural code-level fix for the BadHost class is to read the unmodified ASGI path via request.scope['path'] instead of request.url.path in security-sensitive middleware.

## MITRE ATT&CK

- T1588 Obtain Capabilities
- T1595 Active Scanning
- T1190 Exploit Public-Facing Application
- T1133 External Remote Services
- T1211 Exploitation for Stealth
- T1685 Disable or Modify Tools
- T1212 Exploitation for Credential Access
- T1552 Unsecured Credentials
- T1087 Account Discovery
- T1526 Cloud Service Discovery
- T1213 Data from Information Repositories
- T1550 Use Alternate Authentication Material
- T1078 Valid Accounts
- T1136 Create Account
- T1098 Account Manipulation
- T1518 Software Discovery
- T1059 Command and Scripting Interpreter
- T1567 Exfiltration Over Web Service
- T1496 Resource Hijacking

## Sources

- [GHSA-4xpc-pv4p-pm3w — LiteLLM Authentication Bypass via Host Header Injection](https://github.com/advisories/GHSA-4xpc-pv4p-pm3w)
- [LiteLLM Vulnerability Let Attackers Bypass Authentication via Host Header Injection](https://cybersecuritynews.com/litellm-vulnerability-host-header-injection/)
- [BadHost Breaks Into FastAPI and vLLM With a Single Character (CVE-2026-48710)](https://hackingpassion.com/badhost-starlette-cve-2026-48710/)
- [litellm/proxy/auth/auth_utils.py — get_request_route()](https://github.com/BerriAI/litellm/blob/main/litellm/proxy/auth/auth_utils.py)
- [LiteLLM Release v1.84.0](https://github.com/BerriAI/litellm/releases/tag/v1.84.0)
- [LiteLLM Release Notes v1.84.0 — Reliability hardening + multi-pod budget accuracy](https://docs.litellm.ai/release_notes/v1.84.0/v1-84-0)
- [CVE-2026-42271: LiteLLM Unauthenticated RCE chained with CVE-2026-48710](https://horizon3.ai/attack-research/vulnerabilities/cve-2026-42271-chained-with-cve-2026-48710/)
- [Active Exploitation Alert: CVE-2026-42271 and CVE-2026-48710 — Unauthenticated RCE in LiteLLM via Starlette Host Header Bypass](https://www.rescana.com/post/active-exploitation-alert-cve-2026-42271-and-cve-2026-48710-unauthenticated-rce-in-litellm-ai-gateway-via-starlette-host)
- [LiteLLM Flaw CVE-2026-42271 Exploited in the Wild, Chains to Unauthenticated RCE](https://thehackernews.com/2026/06/litellm-flaw-cve-2026-42271-exploited.html)

## Full data

Detection queries (Splunk SPL / Microsoft KQL / Sigma) and IOC values require the Threadlinqs MCP server (Purple tier): https://intel.threadlinqs.com/mcp

Canonical: https://intel.threadlinqs.com/threat/TL-2026-0833