CVE-2026-35030 — CRITICAL (CVSS 9.1)

Q: Is CVE-2026-35030 actively exploited?

No confirmed active exploitation of CVE-2026-35030 has been reported, but organizations should still patch proactively.

Q: How to fix CVE-2026-35030?

1. Patch: Upgrade litellm to v1.83.0 or later — the cache key now uses a full cryptographic hash of the JWT token. 2. Immediate workaround (if patching is delayed): Set OIDC userinfo cache TTL to 0 to disable caching entirely, or disable JWT authentication. 3. Detection: Audit LiteLLM access logs for anomalies — look for the same user identity accessed from multiple distinct IPs in short windows, or known usernames appearing alongside atypical model usage patterns. 4. Post-incident: If JWT auth and caching were simultaneously active, treat the exposure window as a potential breach; review all API calls for unauthorized model access or data exfiltration, and notify affected users.

Q: What systems are affected by CVE-2026-35030?

This vulnerability affects the following AI/ML architecture patterns: LLM API gateways, model serving, agent frameworks, multi-tenant LLM deployments.

Q: What is the CVSS score for CVE-2026-35030?

CVE-2026-35030 has a CVSS v3.1 base score of 9.1 (CRITICAL). The EPSS exploitation probability is 0.13%.

CISO Take

LiteLLM deployments with JWT/OIDC auth enabled are vulnerable to unauthenticated identity spoofing — an attacker crafts a JWT whose first 20 characters match any cached user's token, which is trivially achievable since all tokens sharing the same signing algorithm have an identical base64url-encoded header prefix by construction. Patch to v1.83.0 immediately; if patching is delayed, set the OIDC userinfo cache TTL to 0. Deployments without JWT auth enabled (the default) are unaffected.

What is the risk?

Critical exploitability for affected configurations. JWT headers are fully deterministic per algorithm — all HS256 tokens share the same first 20 characters, as do all RS256 tokens — meaning any attacker who discovers or guesses the target organization's signing algorithm can manufacture a colliding token without any cryptographic secret. No privileges are required. Once a single legitimate user's session is cached, full identity takeover is possible. Blast radius scales with the privilege level of cached users: LiteLLM often routes to all enterprise LLM providers with per-user billing controls and role-based model access.

What systems are affected?

Package	Ecosystem	Vulnerable Range	Patched
litellm	pip	< 1.83.0	`1.83.0`
47.2K OpenSSF 6.1 4 dependents Pushed 3d ago 55% patched ~42d to patch Full package profile →

Do you use litellm? You're affected.

Severity & Risk

CVSS 3.1

9.1 / 10

EPSS

0.1%

chance of exploitation in 30 days

Higher than 32% of all CVEs

Source: EPSS v3 — FIRST.org

Exploitation Status

No known exploitation

Sophistication

Trivial

Attack Surface

AV Network

AC Low

PR None

UI None

S Unchanged

C High

I High

A None

What should I do?

4 steps

Patch: Upgrade litellm to v1.83.0 or later — the cache key now uses a full cryptographic hash of the JWT token.
Immediate workaround (if patching is delayed): Set OIDC userinfo cache TTL to 0 to disable caching entirely, or disable JWT authentication.
Detection: Audit LiteLLM access logs for anomalies — look for the same user identity accessed from multiple distinct IPs in short windows, or known usernames appearing alongside atypical model usage patterns.
Post-incident: If JWT auth and caching were simultaneously active, treat the exposure window as a potential breach; review all API calls for unauthorized model access or data exfiltration, and notify affected users.

CISA SSVC Assessment

Decision Track*

Exploitation none

Automatable Yes

Technical Impact total

Source: CISA Vulnrichment (SSVC v2.0). Decision based on the CISA Coordinator decision tree.

Classification

Auth Bypass Data Extraction API Framework Inference AML.T0012 - Valid Accounts AML.T0040 - AI Model Inference API Access AML.T0049 - Exploit Public-Facing Application AML.T0106 - Exploitation for Credential Access

Compliance Impact

This CVE is relevant to:

EU AI Act

Article 15 - Accuracy, robustness and cybersecurity

ISO 42001

A.6.1.2 - AI system risk treatment

NIST AI RMF

GOVERN-6.2 - Policies and procedures for AI risk management MANAGE-2.4 - AI risk incident response and recovery

OWASP LLM Top 10

LLM06:2025 - Excessive Agency

Frequently Asked Questions

What is CVE-2026-35030?

LiteLLM deployments with JWT/OIDC auth enabled are vulnerable to unauthenticated identity spoofing — an attacker crafts a JWT whose first 20 characters match any cached user's token, which is trivially achievable since all tokens sharing the same signing algorithm have an identical base64url-encoded header prefix by construction. Patch to v1.83.0 immediately; if patching is delayed, set the OIDC userinfo cache TTL to 0. Deployments without JWT auth enabled (the default) are unaffected.

Is CVE-2026-35030 actively exploited?

No confirmed active exploitation of CVE-2026-35030 has been reported, but organizations should still patch proactively.

How to fix CVE-2026-35030?

1. Patch: Upgrade litellm to v1.83.0 or later — the cache key now uses a full cryptographic hash of the JWT token. 2. Immediate workaround (if patching is delayed): Set OIDC userinfo cache TTL to 0 to disable caching entirely, or disable JWT authentication. 3. Detection: Audit LiteLLM access logs for anomalies — look for the same user identity accessed from multiple distinct IPs in short windows, or known usernames appearing alongside atypical model usage patterns. 4. Post-incident: If JWT auth and caching were simultaneously active, treat the exposure window as a potential breach; review all API calls for unauthorized model access or data exfiltration, and notify affected users.

What systems are affected by CVE-2026-35030?

This vulnerability affects the following AI/ML architecture patterns: LLM API gateways, model serving, agent frameworks, multi-tenant LLM deployments.

What is the CVSS score for CVE-2026-35030?

CVE-2026-35030 has a CVSS v3.1 base score of 9.1 (CRITICAL). The EPSS exploitation probability is 0.13%.

Technical Details

NVD Description

LiteLLM is a proxy server (AI Gateway) to call LLM APIs in OpenAI (or native) format. Prior to 1.83.0, when JWT authentication is enabled (enable_jwt_auth: true), the OIDC userinfo cache uses token[:20] as the cache key. JWT headers produced by the same signing algorithm generate identical first 20 characters. This configuration option is not enabled by default. Most instances are not affected. An unauthenticated attacker can craft a token whose first 20 characters match a legitimate user's cached token. On cache hit, the attacker inherits the legitimate user's identity and permissions. This affects deployments with JWT/OIDC authentication enabled. Fixed in v1.83.0.

Exploitation Scenario

An attacker enumerates a target organization's LiteLLM endpoint and confirms JWT authentication is in use (often disclosed via error messages or OpenAPI docs). They identify the JWT signing algorithm — e.g., RS256 — through discovery or trial-and-error. Because every RS256 JWT begins with the same base64url-encoded header (eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9...), the first 20 characters are identical across all tokens in the system. The attacker crafts a minimal JWT with that algorithm and submits it to the LiteLLM API. If any legitimate user's token is currently cached, the attacker receives a cache hit and is granted that user's full identity — accessing their permitted LLM models, draining their compute budget, and potentially reading prior conversation context injected into agent system prompts.