CVE-2026-49468 is a critical (CVSS 9.8) authentication bypass in the LiteLLM proxy, the AI gateway, before version 1.84.0. A crafted Host header can make the auth layer judge a different route from the one that runs. Upgrade to 1.84.0 or later, and put a layer that validates Host in front of the proxy.
What's affected
- Product: LiteLLM proxy server, installed from PyPI as
litellm. - Affected: versions before 1.84.0.
- Fixed: 1.84.0. The advisory says no configuration change is needed after upgrading.
- Weakness: CWE-290, authentication bypass by spoofing.
- CVSS 9.8 (critical) in the record, vector
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H. The GitHub advisory scores it 9.5 under CVSS 4.0. - Published 22 June 2026. Not marked as exploited in CISA KEV.
The advisory also says most deployments are not affected, because the bypass is blocked by any upstream layer that validates or normalizes the Host header. That includes a CDN or WAF, a reverse proxy with server_name allowlists, or a host-based load balancer. It also says LiteLLM Cloud customers are not affected.
How to check if you're exposed
Check the installed version.
pip show litellm | grep -i '^version'
pip list 2>/dev/null | grep -i litellm
For containers, check the image tag you deploy, and for projects, look in your lock file.
grep -i -A2 '^name = "litellm"' poetry.lock uv.lock 2>/dev/null
grep -i litellm requirements*.txt pyproject.toml 2>/dev/null
Next, ask how clients reach the proxy. If traffic goes through a CDN, WAF, or reverse proxy that rejects unknown Host values, the advisory says the bypass is blocked. If clients or the internet can reach the proxy port directly, you are in the exposed group.
What to do now
- Upgrade
litellmto 1.84.0 or later, rebuild images and redeploy. - Put the proxy behind a layer that validates or normalizes the Host header, such as a reverse proxy with an explicit server_name allowlist.
- Restrict network access to the proxy listener to the clients that need it.
- Check proxy logs for requests to management routes from addresses that should not use them.
- Rotate the master key and any provider API keys stored in the proxy if you saw unexpected management activity.
Why it matters
The proxy decided whether a request was allowed by looking at the route. The advisory explains that the route was derived from the request URL path, which Starlette rebuilds using the Host header. A crafted Host could therefore make the auth check evaluate a different route from the one FastAPI actually served. The check passed on one route and the request ran on another.
That mismatch is the core of CWE-290: trusting a value the client controls. The management routes of an AI gateway are valuable, since they can touch provider keys, spend limits and logs.
Safeguard has a free in-browser dependency scan at gold.safeguard.sh/scan that matches the packages in a manifest against known CVEs. If you build agents or gateways, the same lesson applies to your own code: authorize on the same value you dispatch on.
Try it yourself
Click through it at your own pace, or open it full screen.
Quick check
My proxy sits behind Cloudflare. Am I safe?
The advisory lists a CDN or WAF that validates Host as a blocking layer. Upgrading is still the right fix, since the protection depends on how that layer is set up.
Sources
- GitHub advisory GHSA-4xpc-pv4p-pm3w
- LiteLLM v1.84.0 release
- Red Hat CVE page (named in the record)
- Safeguard Gold entry
Last reviewed: 19 October 2026.
