External risk intelligence

LiteLLM JWT Authentication Cache Bypass Vulnerability

CVE advisorySeverity: CRITICAL (CVSS 9.4)

CVE-2026-35030

LiteLLM is designed as an AI gateway or proxy server, which is commonly deployed as an internet-facing service to facilitate API communication. While the specific vulnerable configuration is not enabled by default, the product's primary role as a network-accessible proxy/gateway makes it likely to be reachable from the internet in common deployment patterns.

Authentication Bypass

Litellm

before 1.83.0

Halo Surface Signal: 4 out of 5 — likely to be public-facing.

External exposure likelihood

Horizon Alert

Summary of the vulnerability and why it matters

A vulnerability in LiteLLM, an AI gateway, could allow an unauthenticated attacker to impersonate legitimate users by exploiting a caching mechanism in its JWT authentication. This issue affects deployments where JWT/OIDC authentication is specifically enabled, as this configuration is not the default.

Unauthorized user access.
Confirm relevance and exposure.
Validate authentication configurations.

Attack Path

How an attacker could exploit the issue

An attacker could potentially impersonate a legitimate user by exploiting a flaw in how LiteLLM caches authentication tokens when JWT authentication is enabled. If an attacker crafts a token with the same first 20 characters as a valid user's cached token, they can trick the system into granting them the user's identity and access rights. This scenario is only possible in deployments that have specifically enabled JWT and OIDC authentication.

Unauthenticated network access required.
Cache key collision allows impersonation.
High risk of unauthorized access.

Live Threat

Current exploitation, exposure, and threat context

When JWT authentication is enabled and the OIDC userinfo cache is active, an unauthenticated attacker could impersonate a legitimate user by crafting a token with a matching prefix. This could allow them to leverage the privileges of the impersonated user, provided the specific configuration is enabled.

User identity and permissions.
Crafted token matching cache key.
Unauthorized access to user resources.

Operational Fix

Recommended remediation, mitigation, and detection steps

For deployments utilizing LiteLLM with JWT/OIDC authentication enabled, the platform or application owner is responsible for addressing this vulnerability. The first practical step is to inventory all LiteLLM instances, confirm if JWT authentication is active, and determine their exposure and business criticality. This information will guide the prioritization and planning of remediation efforts with the responsible teams.

Identify accountable platform or application owners.
Verify JWT authentication and network exposure.
Plan remediation based on criticality and exposure.

Supplementary metadata

CVSS vector

Validate whether this threat affects your internet-facing exposure.

Halo Threat Intelligence helps prioritize remediation with Halo Surface Signal and H/A/L/O context. Start exposure validation with a free external attack surface trial.

Free EASM Trial See How Signal Works

Frequently asked questions

What is LiteLLM and why is it used?

LiteLLM is an AI gateway or proxy server that acts as a central hub for applications to interact with various Large Language Models. It standardizes calls to different LLM providers, such as OpenAI, into a unified format. Developers use it to simplify API management, handle requests, and route traffic between their services and various AI models.

What does CWE-287 and CWE-222 mean for CVE-2026-35030?

This vulnerability involves Improper Authentication (CWE-287) caused by a weakness in the system's caching logic (CWE-222). Because LiteLLM uses only the first 20 characters of a JWT as a cache key, an attacker can create a fake token that shares those same characters. The server mistakenly identifies the attacker as a legitimate user, granting them unauthorized access to the session.

How does an attacker trigger this vulnerability?

An attacker triggers this by submitting a specially crafted authentication token to the proxy. The system fails to distinguish this fake token from a real user's token because they share the same 20-character cache key. Importantly, this issue does not occur if JWT authentication is disabled; it only triggers when a deployment has specifically enabled the 'enable_jwt_auth' configuration option.

Is my LiteLLM instance at risk?

You should investigate if your deployment has JWT or OIDC authentication enabled. According to Halo Surface Signal, LiteLLM is often deployed as an internet-facing gateway, making it highly visible to external traffic. If your configuration is set to use JWT authentication, your risk increases because the gateway is typically network-accessible by design.

What should I do if I am running LiteLLM?

First, verify your configuration to see if 'enable_jwt_auth' is set to true. If it is, you are running an affected setup. Locate all instances of LiteLLM in your environment, assess whether they are reachable from the internet, and update your software to version 1.83.0 or later to patch the caching flaw and secure your authentication process.

References

Written by Nicholas Merritt

Nicholas Merritt is VP of Security Solutions at Halo Security. With more than 25 years across application security, vulnerability prioritization, and offensive security, he helps teams translate threat data into practical exposure validation and remediation focus. He authors Halo Threat Intelligence CVE advisories using Halo Surface Signal and H/A/L/O context to prioritize internet-facing risk.