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

LiteLLM Proxy Authentication Bypass via Host Header (TL-2026-0833), also tracked as BadHost (class), is a critical-severity software vulnerability scored CVSS 9.5, first published 2026-06-17. It has no confirmed attribution, affects BerriAI LiteLLM (litellm proxy), references 1 CVE (CVE-2026-49468), maps to 19 MITRE ATT&CK techniques (T1059, T1078, T1087), and is covered by 9 detection rules and 17 indicators of compromise.

Key facts for TL-2026-0833

Threat ID
TL-2026-0833
Also known as
BadHost (class), GHSA-4xpc-pv4p-pm3w
Severity
CRITICAL
CVSS
9.5 (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)
Status
ACTIVE
Category
VULNERABILITY
First published
2026-06-17
Last reviewed
2026-06-17
Attribution confidence
NONE
Motivation
UNKNOWN
Target sectors
technology, artificial-intelligence, saas, financial, healthcare
Target regions
Global
Detection rules
9
Indicators of compromise
17

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.

How LiteLLM Proxy Authentication Bypass via Host Header works

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 techniques used in TL-2026-0833

Execution

T1059 Command and Scripting Interpreter

Defense Evasion

T1078 Valid Accounts; T1211 Exploitation for Stealth

Discovery

T1087 Account Discovery; T1518 Software Discovery; T1526 Cloud Service Discovery

Persistence

T1098 Account Manipulation; T1136 Create Account

Initial Access

T1133 External Remote Services; T1190 Exploit Public-Facing Application

Credential Access

T1212 Exploitation for Credential Access; T1552 Unsecured Credentials

Collection

T1213 Data from Information Repositories

Impact

T1496 Resource Hijacking

Lateral Movement

T1550 Use Alternate Authentication Material

Exfiltration

T1567 Exfiltration Over Web Service

Resource Development

T1588 Obtain Capabilities

Reconnaissance

T1595 Active Scanning

defense-impairment

T1685 Disable or Modify Tools

Affected products and versions in LiteLLM Proxy Authentication Bypass via Host Header

  • BerriAI — LiteLLM (litellm proxy)
    Vulnerable versions: < 1.84.0
    Fixed in: 1.84.0
  • Encode — Starlette (root-cause BadHost class, CVE-2026-48710)
    Vulnerable versions: < 1.0.1
    Fixed in: 1.0.1

Remediation for LiteLLM Proxy Authentication Bypass via Host Header

Patches

  • LiteLLM >= 1.84.0
  • Starlette >= 1.0.1 (root-cause CVE-2026-48710)

Immediate actions

  • Upgrade LiteLLM to version 1.84.0 or later (no configuration changes required)
  • Restrict network access to the LiteLLM proxy management/admin endpoints to trusted networks only
  • Place the proxy behind a reverse proxy, WAF, CDN, or load balancer that validates and normalizes the HTTP Host header and rejects malformed host values

Workarounds

  • Deploy behind a host-validating reverse proxy / WAF / CDN / load balancer
  • Restrict ingress to management endpoints via network segmentation and allow-lists
  • Reject HTTP requests with malformed Host headers at the perimeter

Longer-term hardening

  • Upgrade Starlette to >= 1.0.1 across all FastAPI/Starlette-based services to remediate the underlying BadHost class (CVE-2026-48710)
  • Audit custom auth middleware to read request.scope['path'] instead of request.url.path when making authorization decisions
  • Rotate all LiteLLM virtual/master keys and provider credentials that may have been exposed while running a vulnerable version
  • Add WAF/reverse-proxy rules to drop requests whose Host header contains '?', '/', '#', or other non-hostname characters
  • Enforce strict allow-listed Host/TRUSTED_HOSTS validation at the application edge

CVEs associated with LiteLLM Proxy Authentication Bypass via Host Header

CVE-2026-49468

Weaknesses (CWE) in LiteLLM Proxy Authentication Bypass via Host Header

CWE-290

Timeline of LiteLLM Proxy Authentication Bypass via Host Header

  • BadHost Starlette Host-header path-confusion class (root cause, CVE-2026-48710) discovered.
  • Starlette 1.0.1 released, fixing the underlying BadHost host-header parsing flaw (CVE-2026-48710).
  • BadHost (CVE-2026-48710) publicly disclosed, detailing single-character Host header auth bypass across FastAPI, vLLM, LiteLLM, and the Python MCP SDK.
  • LiteLLM v1.84.0 released, remediating the Host-header authentication bypass in auth_utils.py::get_request_route().
  • GitHub Security Advisory GHSA-4xpc-pv4p-pm3w / CVE-2026-49468 published for the LiteLLM proxy authentication bypass; fixed in LiteLLM 1.84.0.
  • Active in-the-wild exploitation reported for CVE-2026-42271 (LiteLLM) chained with the Starlette host-header bypass (CVE-2026-48710) to achieve unauthenticated RCE.
  • GHSA-4xpc-pv4p-pm3w updated; Horizon3 and Rescana publish analysis of the LiteLLM RCE chain leveraging the host-header bypass.
  • Cyber Security News reports the LiteLLM Host Header Injection authentication bypass; ingested into the Threadlinqs intelligence pipeline as TL-2026-0833.

Sources cited for LiteLLM Proxy Authentication Bypass via Host Header

Threats related to LiteLLM Proxy Authentication Bypass via Host Header

Detection coverage for TL-2026-0833

As of 2026-06-17, Threadlinqs Intelligence publishes 9 detection rule(s) for TL-2026-0833 across Splunk SPL, Microsoft KQL and Sigma, covering 17 indicator(s) of compromise. The whole corpus is readable without an account; a free account unlocks full detection query text in Splunk SPL, Microsoft KQL and Sigma; paid tiers add raw indicator values, correlation and the MCP server. Threadlinqs MCP server · View plans.

Threadlinqs Intelligence — Real-Time Threat Detection Platform

[ 0 threats ] [ 0 det ] [ CRIT: 0 ] [ HIGH: 0 ]
// threat_feed
$ sort --newest
Showing all threats

Latest Threats