LiteLLM CVE-2026-49468: Host Header Hijack Bypasses AI Gateway Auth

LiteLLM has another critical vulnerability to patch. CVE-2026-49468, disclosed June 17, 2026, is an authentication bypass that lets unauthenticated attackers access protected management endpoints by manipulating the HTTP Host header. The fix landed in version 1.84.0. If you’re running LiteLLM as a proxy, check your version now.

This is the third significant security flaw in LiteLLM this year. We covered CVE-2026-42271, an unauthenticated RCE that landed on the CISA KEV catalog, earlier in 2026. A pre-authentication SQL injection (CVE-2026-42208) was also observed being actively exploited just 36 hours after it was publicly indexed. The pattern is consistent: LiteLLM sits between your application and every AI provider you use, which makes it an unusually attractive target.

What the Vulnerability Is

LiteLLM’s proxy authentication layer determines which route a request is targeting before deciding whether it needs credentials. It does this by reading request.url.path, which Starlette (the ASGI framework underlying LiteLLM) reconstructs from the Host header of the incoming request.

The problem: the Host header is attacker-controlled. If an attacker sends a crafted Host header, Starlette’s path reconstruction produces a different route than the one FastAPI actually dispatches. The auth gate evaluates one path, FastAPI serves another. Protected management endpoints that should require authentication become accessible without it.

The flaw is classified as CWE-290 (Authentication Bypass by Spoofing), affects all LiteLLM versions before 1.84.0, and carries a high CVSS v4 score. The discoverers, Le The Thang of KCSC and Kim Ngoc Chung of One Mount Group, published via GitHub advisory GHSA-4xpc-pv4p-pm3w.

No user interaction is required. Network access is enough.

Why AI Gateways Keep Getting Hit

CVE-2026-49468 is the most recent example of something that’s been consistent across the AI framework vulnerability wave of 2026: the components that aggregate credentials are getting the most attention from attackers.

A typical LiteLLM deployment holds API keys for OpenAI, Anthropic, AWS Bedrock, Azure OpenAI, Cohere, and any other LLM provider the team uses. It also often stores embeddings provider credentials, rate limit configuration, and team-level spend allocations. That’s a single service with the keys to everything.

The April 2026 SQL injection story (CVE-2026-42208) illustrated this directly. Sysdig’s threat research team detected the first exploitation attempt 36 hours and seven minutes after the GitHub Advisory Database indexed the disclosure. The attacker wasn’t scanning broadly. They specifically targeted three database tables: LiteLLM_VerificationToken (virtual API keys), litellm_credentials (provider credentials), and litellm_config (environment variables). The precision suggested prior study of the open-source schema. They knew what they were looking for and went straight for it.

Authentication bypass vulnerabilities like CVE-2026-49468 are often the first step in a similar chain. Access to management endpoints means the ability to read credentials, add new API keys, modify routing configuration, or extract whatever the deployment stores in its backend.

Who’s Affected

LiteLLM versions prior to 1.84.0 are vulnerable. The exposure scope depends on how the instance is deployed:

• Direct internet exposure: Maximum risk. Any attacker can reach the proxy.
• Behind a reverse proxy or WAF that enforces strict Host header validation: The attack path is mitigated at the edge. The upstream component strips or validates the Host header before it reaches LiteLLM.
• Internal-only deployments: Reduced external exposure, but internal access is still a valid threat surface, particularly in environments with lateral movement or insider risk.
• LiteLLM Cloud: Not affected. The hosted service includes upstream controls.

The mitigating factor is meaningful for some deployments. Many production LiteLLM instances sit behind a CDN or reverse proxy, which will typically validate or normalize the Host header. But development environments, internal deployments running without a proxy layer, and any instance exposed to the internet without upstream filtering are at risk.

What to Do

Upgrade to LiteLLM 1.84.0 or later. The fix replaces the route-evaluation logic to use the path FastAPI actually dispatches rather than the Starlette-reconstructed path. No configuration changes are required alongside the upgrade.

pip install litellm --upgrade

If immediate patching isn’t possible: put the LiteLLM proxy behind an upstream component that enforces strict Host header validation. A properly configured nginx, Cloudflare, or any CDN with Host header canonicalization will close this attack path at the edge.

Audit your LiteLLM API keys. Given the track record of targeted attacks against LiteLLM credential storage this year, rotate the provider API keys stored in any LiteLLM instance that has been internet-accessible without an upstream proxy, or that ran a vulnerable version for any extended period. The risk isn’t just authentication bypass through CVE-2026-49468: it’s the history of active exploitation against LiteLLM credential tables demonstrated through CVE-2026-42208.

Check for signs of prior access. If you’ve been running a vulnerable version with network access, review LiteLLM audit logs for unexpected access to management endpoints, API key creation events, or configuration changes. The SQL injection campaign earlier this year showed that attackers move quickly once they have a working exploit.

References

• CyberSecurityNews: Critical LiteLLM Vulnerability Let Attackers Bypass Authentication via Host Header Injection
• GBHackers: Critical LiteLLM Flaw Allows Authentication Bypass via Host Header Injection
• GitLab Advisory Database: CVE-2026-49468: LiteLLM Authentication Bypass via Host Header Injection
• Sysdig: CVE-2026-42208 Targeted SQL Injection Against LiteLLM’s Authentication Path Discovered 36 Hours Following Vulnerability Disclosure