Most recent entries from all

CVE-2026-49468 — LiteLLM: Authentication Bypass via Host Header Injection

Affected: BerriAI litellm, Red Hat Exploit Intelligence, Red Hat Ansible Automation Platform 2, Red Hat OpenShift AI (RHOAI)

LiteLLM is a proxy server (AI Gateway) to call LLM APIs in OpenAI (or native) format. Prior to 1.84.0, a Host-header parsing flaw in the LiteLLM proxy could, under specific conditions, allow unauthenticated access to protected management routes. The auth layer derived the effective route from request.url.path in litellm/proxy/auth/auth_utils.py::get_request_route(), which Starlette reconstructs from the Host header. A crafted Host could therefore make the auth gate evaluate a different route from the one FastAPI dispatched. This vulnerability is fixed in 1.84.0.

GHSA-4xpc-pv4p-pm3w — LiteLLM: Authentication Bypass via Host Header Injection

Affected: PyPI: litellm

### Impact

A Host-header parsing flaw in the LiteLLM proxy could, under specific conditions, allow unauthenticated access to protected management routes.

The auth layer derived the effective route from `request.url.path` in `litellm/proxy/auth/auth_utils.py::get_request_route()`, which Starlette reconstructs from the `Host` header. A crafted `Host` could therefore make the auth gate evaluate a different route from the one FastAPI dispatched.

**Most deployments are not affected.** The bypass is blocked by any upstream layer that validates or normalizes `Host`, such as:

- a CDN or WAF, such as Cloudflare - a reverse proxy with `server_name` allowlists - a host-based load balancer

**LiteLLM Cloud customers are not affected.**

### Patches

Fixed in **`1.84.0`**. Upgrade to `1.84.0` or later. No configuration change is required.

### Workarounds

If upgrading is not immediately possible, place the proxy behind an upstream component that validates or normalizes the `Host` header before forwarding (a CDN/WAF, a reverse proxy with explicit `server_name` allowlists, or a cloud load balancer with host-based routing rules), or otherwise restrict network access to the proxy listener.

### References

- Patched release: [`v1.84.0`](https://github.com/BerriAI/litellm/releases/tag/v1.84.0)

**Discovery Credit**: Le The Thang (KCSC) and Kim Ngoc Chung (One Mount Group)

PYSEC-2026-388 — LiteLLM: Authentication Bypass via Host Header Injection

Affected: PyPI: litellm

### Impact

A Host-header parsing flaw in the LiteLLM proxy could, under specific conditions, allow unauthenticated access to protected management routes. The auth layer derived the effective route from `request.url.path` in `litellm/proxy/auth/auth_utils.py::get_request_route()`, which Starlette reconstructs from the `Host` header. A crafted `Host` could therefore make the auth gate evaluate a different route from the one FastAPI dispatched. **Most deployments are not affected.** The bypass is blocked by any upstream layer that validates or normalizes `Host`, such as:

- a CDN or WAF, such as Cloudflare - a reverse proxy with `server_name` allowlists - a host-based load balancer

**LiteLLM Cloud customers are not affected.**

### Patches

Fixed in **`1.84.0`**. Upgrade to `1.84.0` or later. No configuration change is required.

### Workarounds If upgrading is not immediately possible, place the proxy behind an upstream component that validates or normalizes the `Host` header before forwarding (a CDN/WAF, a reverse proxy with explicit `server_name` allowlists, or a cloud load balancer with host-based routing rules), or otherwise restrict network access to the proxy listener.

### References

- Patched release: [`v1.84.0`](https://github.com/BerriAI/litellm/releases/tag/v1.84.0) **Discovery Credit**: Le The Thang (KCSC) and Kim Ngoc Chung (One Mount Group)