LiteLLM patches OIDC cache key collision auth bypass
TL;DR — LiteLLM’s JWT/OIDC authentication can be bypassed via a userinfo cache key collision, letting an unauthenticated attacker inherit a legitimate user’s identity and permissions in affected deployments.
What happened
LiteLLM is an open-source “AI Gateway” / proxy (distributed as the PyPI package litellm) used to route and normalize calls to many LLM providers.
A GitHub-reviewed advisory (CVE-2026-35030) describes an authentication bypass that occurs when JWT authentication is enabled (enable_jwt_auth: true). In that mode, LiteLLM’s OIDC userinfo cache uses token[:20] (the first 20 characters of the token) as the cache key; the advisory notes that JWT headers produced by the same signing algorithm generate identical first 20 characters.
Per the advisory, an unauthenticated attacker can craft a token whose first 20 characters match a legitimate user’s cached token. If the cache hits, the attacker inherits the legitimate user’s identity and permissions. The advisory emphasizes this is not enabled by default and that most instances are not affected.
This is a high-risk pattern for teams using OIDC/JWT at the gateway layer: token-derived caching is part of the auth boundary, and collisions can turn performance optimizations into identity-confusion vulnerabilities.
Who is impacted
- Deployments using
litellmwith JWT auth enabled (enable_jwt_auth: true). - Deployments relying on OIDC userinfo caching where a cache hit can bind identity/permissions for subsequent requests.
- Versions prior to the advisory’s fixed release.
| Component | Affected versions (per advisory) | Fixed version (per advisory) |
|---|---|---|
PyPI litellm | < 1.83.0 | 1.83.0 |
Notes from the advisory:
- “Most instances are not affected” because JWT auth is not enabled by default.
- The impact described is unauthenticated impersonation on cache hit.
What to do now
- Follow vendor remediation guidance and apply the patched release.
-
"Fixed in v1.83.0."
-
- If you cannot patch immediately, apply the advisory’s workarounds:
-
"Disable OIDC userinfo caching by setting the cache TTL to 0, or disable JWT authentication entirely."
-
- Validate exposure in your environment:
- Identify where
enable_jwt_auth: trueis configured and whether OIDC userinfo caching is enabled. - Review gateway logs/telemetry for anomalous authentication behavior consistent with repeated token attempts targeting cache collisions.
- Identify where
Content is AI-assisted and reviewed by our team, but issues may be missed and best practices evolve rapidly, send corrections to [email protected]. Always consult official documentation and validate key implementation decisions before making design or security choices.
