Critical LiteLLM Flaw Can Allow Authentication Bypass Through Host Header Injection

A critical vulnerability in LiteLLM can allow unauthenticated access to protected management routes in some proxy server deployments. The flaw is tracked as CVE-2026-49468 and affects LiteLLM versions before 1.84.0.

The issue is a Host header parsing flaw in the LiteLLM proxy. According to the GitHub Advisory Database, a crafted Host header could make the authentication layer check a different route from the one the application actually serves.

LiteLLM has already patched the problem in version 1.84.0. The company also says follow-up hardening was later backported across maintained release lines, according to the LiteLLM security post.

LiteLLM proxy users should upgrade to version 1.84.0 or later

The vulnerability matters because LiteLLM often sits in front of large language model APIs as an AI gateway. Organizations use it to route model requests, manage virtual keys, track spending, and centralize access to providers such as OpenAI, Anthropic, Azure, Bedrock, Vertex AI, and others.

That role can make a vulnerable proxy a sensitive target. If an attacker can reach an affected LiteLLM proxy listener and send arbitrary Host headers, the authentication bypass could expose management functionality that should require authorization.

The GitLab Advisory Database lists the issue as critical and says all versions before 1.84.0 are affected. It also maps the weakness to CWE-290, Authentication Bypass by Spoofing.

Item	Details
CVE	CVE-2026-49468
Advisory	GHSA-4xpc-pv4p-pm3w
Affected package	litellm on PyPI
Affected versions	Versions before 1.84.0
Patched version	1.84.0 or later
Severity	Critical, CVSS 9.5 in GitHub’s advisory

How the authentication bypass works

The flaw comes from a mismatch between route checking and request handling. LiteLLM’s authentication layer derived the effective route from request.url.path. Starlette reconstructs that value using the Host header supplied by the client.

If an attacker controls the Host header, the authentication layer can evaluate one route while FastAPI dispatches the request to another. That gap can cause a protected management route to be treated as public under the right deployment conditions.

The GitHub advisory says the attack has a network vector, low attack complexity, no required privileges, and no user interaction. However, the attack requires certain deployment conditions, so not every LiteLLM installation is exposed.

Most deployments are not automatically exposed

LiteLLM says the issue affects a limited set of proxy server deployments. The Python SDK is not affected, and LiteLLM Cloud customers are also not affected.

A deployment is potentially at risk if it runs the LiteLLM proxy server, uses a version older than 1.84.0, and exposes the proxy listener to untrusted clients that can send arbitrary Host headers.

The company’s security note says infrastructure that validates or normalizes the Host header can reduce exposure. Examples include a CDN, WAF, reverse proxy with explicit server_name allowlists, or a cloud load balancer with host-based routing rules.

• The issue affects LiteLLM proxy server deployments, not the LiteLLM Python SDK.
• LiteLLM Cloud customers are not affected.
• Deployments behind strict Host header validation are less likely to be exposed.
• Reverse proxies that pass the client Host header unchanged may not fully protect affected systems.

What admins should do now

The main fix is to upgrade LiteLLM to version 1.84.0 or later. LiteLLM also recommends using the latest release because additional path-handling hardening was added after the first fix.

Organizations that had an affected proxy reachable from an untrusted network should also rotate API keys created during the exposure window. They should review management audit logs for unexpected changes to keys, users, or settings.

If an immediate upgrade is not possible, admins should place the proxy behind trusted infrastructure that validates or normalizes Host headers. Network access to the proxy listener should also be restricted where possible.

Action	Priority	Why it matters
Upgrade to LiteLLM 1.84.0 or later	High	Removes the known authentication bypass condition
Move to the latest maintained release	High	Includes additional route path-handling hardening
Validate or normalize Host headers upstream	Medium	Reduces exposure while teams complete upgrades
Restrict network access to the proxy	Medium	Limits access from untrusted clients
Rotate affected API keys and review logs	Medium	Helps detect or limit damage if the proxy was exposed

Why AI gateway security is under more scrutiny

The flaw comes at a time when AI gateways are becoming important infrastructure inside companies. LiteLLM describes itself as an open-source AI gateway for calling more than 100 LLM providers through a unified interface, according to the LiteLLM repository.

These systems often handle API keys, model access rules, budgets, logs, and user permissions. A weakness in the gateway can therefore affect more than one model provider or application.

The GitLab listing also highlights why dependency and container scanning matter for AI infrastructure. Teams that self-host LiteLLM should track proxy updates the same way they track updates for web servers, identity systems, and API gateways.

The practical advice is clear: update LiteLLM, check whether the proxy was reachable from untrusted networks, and avoid relying only on edge filtering as a permanent fix. Host header validation helps, but upgrading remains the safest remediation.

FAQ