Which versions of LiteLLM are affected by CVE-2026-49468?

LiteLLM proxy versions before 1.84.0 contain a critical authentication bypass allowing unauthenticated attackers to access protected management interfaces when directly exposed to networks; no public…. A patch is available.

How to fix or mitigate CVE-2026-49468?

Within 24 hours: Inventory all LiteLLM proxy deployments and identify instances exposed directly to untrusted networks without upstream Host-header validation. Within 7 days: Upgrade all affected instances to LiteLLM proxy version 1.84.0 or later. Within 30 days: Verify patches are deployed across all environments and implement network segmentation restricting management route access to trusted administrative networks.

LiteLLM CVE-2026-49468

Q: What is the CVSS score of CVE-2026-49468?

CVE-2026-49468 has a CVSS 4.0 base score of 9.5 (Critical). CVSS vector: CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X. EPSS exploitation probability: 0.4%.

EUVD-2026-38361 CRITICAL

Authentication Bypass by Spoofing (CWE-290)

2026-06-16 https://github.com/BerriAI/litellm

GHSA-4xpc-pv4p-pm3w

Authentication Bypass

9.5

CVSS 4.0 · Vendor: https://github.com/BerriAI/litellm

Severity by source

Vendor (https://github.com/BerriAI/litellm) PRIMARY

9.5 CRITICAL

CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X

vuln.today AI

8.1 HIGH

Network-reachable, no auth or UI; AC:H reflects the required absence of upstream Host validation; full C/I/A impact via management routes; scope unchanged.

3.1 AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H

4.0 AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N

Red Hat

8.1 HIGH

qualitative

Primary rating from Vendor (https://github.com/BerriAI/litellm).

CVSS VectorVendor: https://github.com/BerriAI/litellm

CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X

Attack Vector

Network

Attack Complexity

Low

Privileges Required

None

User Interaction

None

Scope

Lifecycle Timeline

Analysis Updated

Jun 22, 2026 - 21:44 vuln.today

v3 (cvss_changed)

Analysis Updated

Jun 22, 2026 - 21:44 vuln.today

v2 (cvss_changed)

Re-analysis Queued

Jun 22, 2026 - 21:39 vuln.today

cvss_changed

CVSS changed

Jun 22, 2026 - 21:39 NVD

9.5 (CRITICAL)

Source Code Evidence Fetched

Jun 17, 2026 - 00:16 vuln.today

Analysis Generated

Jun 17, 2026 - 00:16 vuln.today

Blast Radius

ecosystem impact

† from your stack dependencies † transitive graph · vuln.today resolves 4-path depth

11 pypi packages depend on litellm (9 direct, 2 indirect)

Ecosystem-wide dependent count for version 1.84.0.

DescriptionCVE.org

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

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

AnalysisAI

Authentication bypass in LiteLLM proxy versions prior to 1.84.0 allows unauthenticated attackers to reach protected management routes by sending a crafted Host header that causes Starlette to reconstruct request.url.path inconsistently with the route FastAPI actually dispatches. The flaw lives in get_request_route() in litellm/proxy/auth/auth_utils.py and only impacts deployments that expose the proxy listener directly without an upstream Host-validating layer; no public exploit identified at time of analysis.

Technical ContextAI

LiteLLM is a widely used Python proxy/gateway for routing requests to LLM providers, built on FastAPI and Starlette. The vulnerable code path is in litellm/proxy/auth/auth_utils.py::get_request_route(), which derives the effective route from request.url.path - a value Starlette reconstructs using the client-supplied Host header. Because the auth gate and the FastAPI dispatcher resolve the request differently when Host is manipulated, the authorization check can be evaluated against one route while a different (management) route is actually executed. This is the classic CWE-290 (Authentication Bypass by Spoofing) pattern, where a trust decision relies on attacker-controlled input. The affected package per CPE is pkg:pip/litellm in versions below 1.84.0.

RemediationAI

Vendor-released patch: 1.84.0 - upgrade pip install litellm>=1.84.0 (note the vendor flags this as a release containing breaking changes, so review the v1.84.0 release notes at https://docs.litellm.ai/release_notes/v1.84.0/v1-84-0 before rolling forward). No configuration change is required after upgrade. If immediate upgrade is not possible, front the proxy with an upstream component that validates or normalizes the Host header before forwarding: a CDN/WAF such as Cloudflare, an nginx/Apache reverse proxy with explicit server_name allowlists, or a cloud load balancer using host-based routing rules - each rejects requests bearing arbitrary Host values, which neutralizes the bypass at the cost of one extra hop and the need to maintain a hostname allowlist. Alternatively, restrict network reachability to the proxy listener (firewall, VPN-only, or bind to localhost behind a trusted fronting service) so only validated traffic reaches LiteLLM. See the advisory at https://github.com/BerriAI/litellm/security/advisories/GHSA-4xpc-pv4p-pm3w for full guidance.