LiteLLM CVE-2026-49468: a Host-header auth bypass in the gateway's own routing

What is this?

On June 17, 2026, a critical authentication-bypass vulnerability in LiteLLM was published in the GitHub Advisory Database as GHSA-4xpc-pv4p-pm3w and assigned CVE-2026-49468. LiteLLM is one of the most widely deployed LLM proxies/gateways — the model-routing layer underneath CrewAI, DSPy, Microsoft GraphRAG and a long tail of agent frameworks — so a pre-auth flaw in its proxy reaches a very large surface.

The bug is a Host-header injection that bypasses LiteLLM’s own authorization layer (CWE-290, Authentication Bypass by Spoofing). It affects all versions before 1.84.0 and is fixed in 1.84.0. The advisory rates it critical, with a high CVSS v4 score: network vector, low complexity, no authentication and no user interaction required. It was reported responsibly by Le The Thang (KCSC) and Kim Ngoc Chung (One Mount Group).

If this sounds familiar, it should. It is the application-layer cousin of BadHost (CVE-2026-48710), the May 2026 Starlette flaw of the same shape — and it shows the bug class survives a framework patch.

How it works

LiteLLM decides which route an incoming request maps to inside get_request_route() in litellm/proxy/auth/auth_utils.py. That function reads request.url.path to compute the effective path used for the authorization decision.

In Starlette-based applications, request.url is reconstructed from the client-supplied Host header. So request.url.path is partly attacker-influenced. FastAPI, meanwhile, dispatches the request to a handler using the path taken from the ASGI request line — a different source of truth. By crafting the Host header, an attacker makes the path the auth layer evaluates diverge from the path FastAPI actually executes.

# Conceptual sketch based on the public June 17, 2026 advisory.
# No payload against any live system is reproduced here.

Auth layer  (get_request_route → request.url.path, Host-derived):
    sees a benign / non-privileged path  → check passes

FastAPI router (path from ASGI request line):
    dispatches the privileged management endpoint → handler runs

The result: a request that should be rejected by access control reaches a restricted management endpoint anyway. The root cause is the same as BadHost — a security decision made on a value derived from a client-controlled header — except here it lives in LiteLLM’s own code, not in Starlette. Patching the framework did not remove the pattern; the application had reimplemented it.

Crucially, not every deployment is exploitable. Per the advisory, environments that normalize or validate the Host header upstream are effectively protected: CDNs, WAFs, reverse proxies with strict server_name validation, and cloud load balancers with host-based routing all strip or reject the manipulation before it reaches LiteLLM. LiteLLM Cloud customers are not affected. The realistic at-risk profile is a LiteLLM proxy exposed more or less directly to an untrusted network with no host validation in front of it.

Why it matters

A gateway is a concentration point. The reason teams put LiteLLM in front of their models is precisely to centralize keys, budgets, rate limits and routing — which means its management endpoints sit on top of every provider credential and policy the proxy fronts. An unauthenticated reach into those endpoints is high-value, and LiteLLM has now had a pre-auth SQL injection, an MCP-endpoint RCE chain and this auth bypass disclosed inside roughly two months.

The deeper point is the recurrence of the class. BadHost was patched at the Starlette layer in 1.0.1. Yet the same “trust a Host-derived path for an auth decision” mistake reappeared one layer up, in LiteLLM’s own routing helper, with its own CVE and its own fix. Framework patches do not retroactively fix application code that re-derives the same untrusted value. If you tracked BadHost and assumed your gateway was therefore clean, that assumption was wrong.

Defenses

Upgrade LiteLLM to 1.84.0 or later. This is the fix, and the advisory notes it requires no configuration changes — pin the dependency, rebuild, redeploy. Treat it as a priority patch for any internet-reachable proxy.

Put a Host-validating layer in front of the proxy. If you cannot upgrade immediately, place LiteLLM behind a CDN, WAF, or reverse proxy that enforces strict Host / server_name validation, or a load balancer with host-based routing. Reject any request whose Host header contains /, ?, #, whitespace or bytes outside the RFC 9112 authority grammar. This both mitigates CVE-2026-49468 and hardens against the next variant.

Restrict network exposure. A model gateway rarely needs to be reachable from the open internet. Bind it to an internal plane, gate management endpoints behind mTLS or client certificates, and apply least-privilege network policy so the proxy is only reachable from the services that legitimately call it.

Stop authorizing on header-derived paths. The architectural lesson, identical to BadHost: never make an authorization decision on a value reconstructed from a client-controlled header. In ASGI/Starlette code, base routing and access checks on scope["path"] (from the request line), not on request.url.path (Host-derived). Audit any custom middleware and routing helpers in your own stack for the same pattern.

Inventory your gateway’s CVE cadence. Given the run of LiteLLM disclosures, subscribe to the project’s GitHub Security Advisories, track GHSA IDs in your dependency scanner, and set an explicit, short patch SLA for the component that fronts your model keys.

Status

Item	Reference	Date	Notes
Public advisory	GitHub GHSA-4xpc-pv4p-pm3w / CVE-2026-49468	2026-06-17	Critical, CWE-290
Affected versions	LiteLLM < 1.84.0	—	Proxy auth layer
Fixed release	LiteLLM 1.84.0	2026-06-17	No config change required
Root cause	get_request_route() reads Host-derived request.url.path	—	Auth/route desync
Not affected	LiteLLM Cloud; deployments behind Host-validating CDN/WAF/reverse proxy/LB	—	Upstream normalizes Host
Reporters	Le The Thang (KCSC), Kim Ngoc Chung (One Mount Group)	2026-06-17	Responsible disclosure
Related class	BadHost (CVE-2026-48710), Starlette < 1.0.1	2026-05-22	Same desync, framework layer

The headline isn’t “another LiteLLM bug.” It is that a host-header path desync, already fixed once in the framework, came back in the gateway’s own code — proof that this bug class needs a pattern-level defense (never authorize on a header-derived path), not just a version bump.