CVE-2026-35030: LiteLLM has an authentication bypass via OIDC userinfo cache key collision
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.
Security readout for executives and security teams
Plain-English summary
CVE-2026-35030 lets an unauthenticated attacker be treated as another user in specific LiteLLM gateway deployments. The risky setup is JWT/OIDC authentication enabled on versions before 1.83.0. Most instances are reportedly not affected because this option is off by default.
Executive priority
Treat as urgent for affected LiteLLM AI gateways because it can bypass authentication and inherit another user's permissions. Reduce priority only after confirming JWT/OIDC authentication is disabled or the deployment is upgraded.
Technical view
Prior to LiteLLM 1.83.0, the OIDC userinfo cache key used only the first 20 token characters. Tokens sharing that prefix could collide, causing cached userinfo for a legitimate user to be reused and granting that user's identity and permissions.
Likely exposure
Exposure is limited to BerriAI LiteLLM versions below 1.83.0 with enable_jwt_auth: true and OIDC userinfo caching in use. Deployments using defaults without JWT authentication are described as generally unaffected.
Exploitation context
The bundle does not cite active exploitation, and KEV is false. Exploitation requires a cache-hit condition against a legitimate user's cached token context, but no public exploit status is provided in the supplied sources.
Researcher notes
The core weakness is a cache-key collision caused by truncating JWT-derived cache keys. The source bundle identifies CWE-222 and CWE-287, CVSS 4.0 score 9.4, and a fix in 1.83.0, but does not provide exploit telemetry.
Mitigation direction
Upgrade LiteLLM to version 1.83.0 or later.
Confirm whether enable_jwt_auth is enabled in LiteLLM configuration.
Prioritize internet-facing or multi-tenant LiteLLM gateways.
Review Red Hat advisories if consuming LiteLLM through Red Hat packages.
If upgrade is delayed, check vendor guidance for supported interim controls.
Validation and detection
Inventory all LiteLLM deployments and record running versions.
Inspect configuration for enable_jwt_auth: true.
Confirm whether OIDC/JWT authentication is used in production paths.
Review gateway logs for unexpected identity switches or permission mismatches.
Verify patched systems report LiteLLM 1.83.0 or later.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Potential ATT&CK relevance
Conservative CVE-to-ATT&CK context
These mappings and lookup hints may be relevant to the vulnerability behavior, CWE, affected product, or exposure path. Glexia-inferred context is not an official MITRE, ATT&CK, CWE, or CVE Program mapping.
ATT&CK lookup starting points
Use these exact CWE pages and searches to review the Glexia ATT&CK library from this CVE's weakness and description context.
cwe · low confidence lookup
CWE-222: Exact CWE lookup
Use the exact CWE identifier as the starting point before reviewing related ATT&CK behavior. Open the exact CWE lookup page first, then review the ATT&CK searches from that MITRE weakness context. This is a Glexia lookup hint, not an official ATT&CK mapping.
Authentication and credential weaknesses can make valid-account abuse and credential telemetry useful review starting points. Open the exact CWE lookup page first, then review the ATT&CK searches from that MITRE weakness context. This is a Glexia lookup hint, not an official ATT&CK mapping.
The CVE wording references authentication or credential exposure, so valid-account and credential-access review may help. This is a Glexia inferred lookup path, not an official MITRE, ATT&CK, or CVE Program mapping.
These fields come from the CVE record and ADP containers, not from Glexia's Take. They preserve time-varying source decisions such as CISA SSVC, KEV status, CVSS metrics, and provider references.
3CVSS vectors
5Timeline events
2ADP providers
8Source links
SSVC decision data
CISA-ADPCISA Coordinator
Timestamp
Version
2.0.3
Exploitation: noneAutomatable: yesTechnical Impact: total
CVSS vector scores
3 official scores
We collect every scored CVSS vector available in the official CNA and ADP containers. When more than one version is present, the table keeps the source vectors side by side instead of collapsing them into the highest score.
CWE links open Glexia weakness intelligence pages with official CWE context, developer remediation guidance, and related CVE mappings.
CWE-222 · source CWE mapping
Truncation of Security-relevant Information
Truncation of Security-relevant Information represents a recurring weakness pattern that can create exploitable paths when design, validation, or implementation controls are missing.
Improper Authentication represents a recurring weakness pattern that can create exploitable paths when design, validation, or implementation controls are missing.