CVE-2026-35030
CRITICAL
GHSA-jjhc-v7c2-5hh6
CVSS Vector
CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:H/VA:N/SC:H/SI:H/SA:N/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
Lifecycle Timeline
3Description
### Impact 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. ### Patches Fixed in v1.83.0. The cache key now uses the full hash of the JWT token. ### Workarounds Disable OIDC userinfo caching by setting the cache TTL to 0, or disable JWT authentication entirely.
Analysis
Authentication bypass in LiteLLM's JWT/OIDC implementation allows unauthenticated attackers to impersonate legitimate users via cache key collision. When JWT authentication is enabled (non-default configuration), the userinfo cache uses only the first 20 characters of the token as a key. …
Sign in for full analysis, threat intelligence, and remediation guidance.
Remediation
Within 24 hours: Inventory all deployments of LiteLLM and identify instances with JWT/OIDC authentication enabled (non-default). Within 7 days: Upgrade all affected LiteLLM instances to version 1.83.0 or later; if immediate upgrade is not feasible, disable JWT/OIDC authentication or implement network-level access controls. …
Sign in for detailed remediation steps.
Priority Score
Share
External POC / Exploit Code
Leaving vuln.today