LiteLLM JWT Authentication Cache Key Collision

Executive Summary

A critical authentication bypass vulnerability (CVE-2026-35030, CWE-287) in LiteLLM, an AI gateway proxy used to route requests to multiple LLM APIs, allows an unauthenticated attacker to hijack legitimate user sessions through OIDC userinfo cache key collision (GHSA-jjhc-v7c2-5hh6). This vulnerability only affects deployments where JWT authentication is explicitly enabled (enable_jwt_auth: true), which is not the default configuration; the NVD description states that the majority of LiteLLM instances are unaffected (NVD). The vulnerability is fixed in version 1.83.0, which replaces the truncated cache key with a full token hash (GHSA-jjhc-v7c2-5hh6). Organisations running LiteLLM with JWT/OIDC authentication enabled on versions prior to 1.83.0 should upgrade immediately (NVD).

Risk Rating

Affected Products

Sources: NVD CPE match cpe:2.3:a:litellm:litellm:*:*:*:*:*:*:*:* with versionEndExcluding 1.83.0 (https://nvd.nist.gov/vuln/detail/CVE-2026-35030); GHSA-jjhc-v7c2-5hh6 first_patched_version 1.83.0 (https://github.com/BerriAI/litellm/security/advisories/GHSA-jjhc-v7c2-5hh6).

Am I Affected?

1. Check whether your environment installs litellm from PyPI: pip show litellm
2. Check installed version: if the version is below 1.83.0, the code contains the vulnerable cache key logic
3. Check configuration: the vulnerability only applies when enable_jwt_auth: true is set. If JWT authentication is not enabled, the deployment is not affected regardless of version (NVD)
4. Check whether OIDC userinfo caching is active (not explicitly disabled) (GHSA-jjhc-v7c2-5hh6)

Abstract

CVE-2026-35030 is an improper authentication vulnerability (CWE-287) in the OIDC userinfo cache of LiteLLM, a proxy server (AI Gateway) that routes requests to multiple LLM APIs in OpenAI-compatible format (NVD). The vulnerability requires JWT authentication to be explicitly enabled (enable_jwt_auth: true), which is not the default configuration; the NVD description states that the majority of LiteLLM instances are unaffected (NVD). When JWT authentication is active, the cache uses token[:20] (the first 20 characters of the JWT) as the cache key (GHSA-jjhc-v7c2-5hh6). JWT headers produced by the same signing algorithm generate identical first 20 characters, creating a predictable collision space (NVD). 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 (NVD). The fix in version 1.83.0 replaces the truncated key with a full hash of the JWT token (GHSA-jjhc-v7c2-5hh6). No public proof-of-concept exploit code is available at the time of writing (GHSA-jjhc-v7c2-5hh6).

Key Findings

1. Cache key collision via truncation: The OIDC userinfo cache in LiteLLM uses token[:20] as the cache key. JWTs produced by the same signing algorithm share identical first 20 characters in the header portion, making collisions predictable rather than probabilistic (GHSA-jjhc-v7c2-5hh6).

2. Unauthenticated exploitation: The CVSS vector includes PR:N (privileges required: none). An attacker does not need a valid account or any prior authentication to exploit this vulnerability (NVD).

3. Identity inheritance on collision: A successful cache hit returns the cached userinfo of a legitimate user, granting the attacker that user's identity and all associated permissions within the LiteLLM proxy (NVD).

4. Non-default prerequisite limits scope: The enable_jwt_auth configuration option is not enabled by default. The NVD description explicitly states that the majority of LiteLLM instances are unaffected (NVD). Only organisations that have deliberately enabled JWT/OIDC authentication are at risk.

5. No public PoC: No proof-of-concept exploit code has been published as of the date of this report (GHSA-jjhc-v7c2-5hh6). FIRST.org EPSS rates the probability of exploitation at 0.00085 (24.6th percentile) (FIRST.org EPSS).

Attack Flow

Prerequisites:
  - LiteLLM < 1.83.0
  - enable_jwt_auth: true
  - Legitimate userinfo is cached

+--------------------------------------------+
| 1. Attacker infers JWT signing algorithm   |
|    used by the target OIDC provider        |
+---------------------+----------------------+
                      |
                      v
+--------------------------------------------+
| 2. Attacker crafts JWT with same header    |
|    Same alg => same first 20 characters    |
+---------------------+----------------------+
                      |
                      v
+--------------------------------------------+
| 3. Crafted token reaches LiteLLM proxy     |
+---------------------+----------------------+
                      |
                      v
+--------------------------------------------+
| 4. Cache lookup uses key = token[:20]      |
|    Key matches legitimate cached userinfo  |
+---------------------+----------------------+
                      |
                      v
+--------------------------------------------+
| 5. Proxy returns cached legitimate user    |
|    identity instead of attacker identity   |
+---------------------+----------------------+
                      |
                      v
+--------------------------------------------+
| 6. Attacker accesses LLM APIs as user      |
|    Impact: confidentiality and integrity   |
+--------------------------------------------+

Prerequisites: LiteLLM < 1.83.0 with enable_jwt_auth: true (not default) (NVD); a legitimate user must have an active cached session (RAXE assessment); attacker must know or infer the signing algorithm used by the target's JWT provider (GHSA-jjhc-v7c2-5hh6).

Technical Details

Vulnerability Mechanics

LiteLLM is a proxy server (AI Gateway) that provides a unified OpenAI-compatible interface to multiple LLM APIs (NVD). When JWT authentication is enabled via the enable_jwt_auth: true configuration option, the proxy validates incoming JWT tokens against an OIDC provider and caches the resolved userinfo to avoid repeated provider lookups (GHSA-jjhc-v7c2-5hh6).

The cache key is constructed as token[:20] (the first 20 characters of the Base64url-encoded JWT) (GHSA-jjhc-v7c2-5hh6). A standard JWT consists of three Base64url-encoded segments: header, payload, and signature, separated by dots. The header segment encodes the token type and signing algorithm. For any given signing algorithm (e.g., RS256), the header segment is deterministic; all tokens produced with that algorithm share an identical header encoding. When the header segment exceeds 20 characters, token[:20] is drawn entirely from this deterministic prefix, making collisions between any two tokens signed with the same algorithm a certainty rather than a statistical event (NVD; GHSA-jjhc-v7c2-5hh6).

An unauthenticated attacker who knows or can infer the signing algorithm in use can craft a JWT whose first 20 characters match any legitimate user's cached token. When this crafted token is presented to the LiteLLM proxy, the cache returns the legitimate user's userinfo, and the attacker inherits that user's identity and permissions for the duration of the cache entry's lifetime (NVD).

CVSS and Severity

NVD analysis status: The NVD entry for CVE-2026-35030 has vulnStatus "Analyzed", meaning NVD has completed its analysis and confirmed the CPE match (cpe:2.3:a:litellm:litellm:*:*:*:*:*:*:*:* with versionEndExcluding 1.83.0) (NVD). The CVSS 3.1 score of 9.1 is present in NVD as a Secondary (CNA-submitted) score; no NVD Primary CVSS 3.1 score has been published (NVD).

CVSS Divergence Note

The NVD CVSS 3.1 score is 9.1; the GHSA CVSS 4.0 score is 9.4. These scores use different CVSS versions (3.1 vs 4.0) and are not directly comparable. The CVSS 4.0 vector includes AT:P (Attack Requirements: Present), reflecting the prerequisite that JWT authentication must be enabled, which is not captured as a distinct metric in CVSS 3.1. Both scoring systems rate the vulnerability as critical. This publication uses the CVSS 3.1 score of 9.1 for severity language, as it is the score present in NVD under the v3.1 metric (NVD).

Impact

Successful exploitation results in (NVD):

• Confidentiality: HIGH: attacker can access all resources and data available to the hijacked user identity, including prompts, responses, and API keys routed through the proxy
• Integrity: HIGH: attacker can perform actions under the hijacked identity, including modifying configurations, routing rules, and model selections
• Availability: NONE: no denial-of-service impact is described

Attack Prerequisites

1. Target LiteLLM instance must be running a version prior to 1.83.0 (NVD)
2. JWT authentication must be explicitly enabled (enable_jwt_auth: true); this is not the default configuration (NVD)
3. OIDC userinfo caching must be active (not explicitly disabled) (GHSA-jjhc-v7c2-5hh6)
4. A legitimate user must have an active cached session for the collision to succeed (RAXE assessment)
5. The attacker must know or be able to infer the signing algorithm used by the target's OIDC provider (GHSA-jjhc-v7c2-5hh6)

Exploit Prediction

FIRST.org EPSS rates CVE-2026-35030 at 0.00085 (24.6th percentile), indicating low predicted exploitation probability (FIRST.org EPSS). No public proof-of-concept exploit code has been published (GHSA-jjhc-v7c2-5hh6).

Confidence and Validation

Assessment Confidence: High

Detection Signatures

Detection Limitations

• This vulnerability only affects LiteLLM deployments with enable_jwt_auth: true, which is not the default configuration (NVD)
• Detecting JWT cache key collision requires access to LiteLLM application logs or proxy access logs with token content; many deployments may not log JWT tokens at sufficient granularity (RAXE assessment)
• The cache collision is based on the first 20 characters of the JWT matching; detecting this requires comparing token prefixes across requests, which is non-trivial in standard logging configurations (RAXE assessment)
• Configuration audit (Rule 2) is the recommended detection approach for the majority of affected organisations (RAXE assessment)

Rule 1: LiteLLM Multiple Identities from Similar JWT Prefix (Hunting)

Classification: Hunting rule; requires custom instrumentation Severity Tier: Medium

Detects multiple distinct user identities associated with JWTs sharing the same prefix characters in LiteLLM logs, which may indicate cache key collision exploitation per CVE-2026-35030 (GHSA-jjhc-v7c2-5hh6). Requires custom log enrichment that captures JWT prefix data; not available in default LiteLLM logging.

title: LiteLLM JWT Cache Key Collision - Multiple Identities
id: raxe-2026-053-sigma-001
status: experimental
description: >
  Hunting rule for LiteLLM JWT authentication cache key collision.
  CVE-2026-35030 uses token[:20] as cache key; JWTs from the same
  algorithm share identical prefixes, enabling identity hijack on cache
  hit (GHSA-jjhc-v7c2-5hh6). Requires custom instrumentation to log
  JWT prefix and resolved identity. Not available in default logging.
references:
  - https://nvd.nist.gov/vuln/detail/CVE-2026-35030
  - https://github.com/BerriAI/litellm/security/advisories/GHSA-jjhc-v7c2-5hh6
author: RAXE Labs
date: 2026/04/12
tags:
  - attack.credential_access
  - attack.t1550.001
  - cve.2026.35030
logsource:
  category: application
  product: litellm
detection:
  selection:
    EventType: 'auth_cache_hit'
  filter_normal:
    TokenOwner|equals: '%RequestIdentity%'
  condition: selection and not filter_normal
level: medium
falsepositives:
  - Token refresh events where the same user presents a new token
  - Load balancer retry with different request metadata

Rule 2: LiteLLM Vulnerable JWT Authentication Configuration (Posture)

Classification: Posture/exposure rule Severity Tier: Medium

Detects LiteLLM configuration with JWT authentication enabled on a version prior to 1.83.0, which is vulnerable to CVE-2026-35030 (NVD). This is a configuration audit rule for identifying exposed deployments.

title: LiteLLM Vulnerable JWT Auth Configuration (Pre-1.83.0)
id: raxe-2026-053-sigma-002
status: experimental
description: >
  Posture rule detecting LiteLLM deployments with enable_jwt_auth enabled
  on versions prior to 1.83.0. CVE-2026-35030 affects JWT-auth-enabled
  deployments where the OIDC userinfo cache uses token[:20] as cache key
  (NVD). Fixed in v1.83.0 (NVD). Instances without JWT auth are
  unaffected (NVD); this is the default configuration.
references:
  - https://nvd.nist.gov/vuln/detail/CVE-2026-35030
  - https://github.com/BerriAI/litellm/security/advisories/GHSA-jjhc-v7c2-5hh6
author: RAXE Labs
date: 2026/04/12
tags:
  - attack.initial_access
  - attack.t1078
  - cve.2026.35030
logsource:
  category: application
  product: litellm
detection:
  selection_config:
    ConfigKey: 'enable_jwt_auth'
    ConfigValue: 'true'
  selection_version:
    ApplicationVersion|lt: '1.83.0'
  condition: selection_config and selection_version
level: medium
falsepositives:
  - LiteLLM v1.83.0+ with JWT auth enabled (patched, not vulnerable)

Remediation

Upgrade to LiteLLM 1.83.0 or Later

pip install "litellm>=1.83.0"

The fix replaces the token[:20] cache key with a full hash of the JWT token, eliminating the collision attack surface (GHSA-jjhc-v7c2-5hh6). Source: NVD (https://nvd.nist.gov/vuln/detail/CVE-2026-35030); GHSA-jjhc-v7c2-5hh6 (https://github.com/BerriAI/litellm/security/advisories/GHSA-jjhc-v7c2-5hh6).

Interim Mitigations

If immediate upgrade is not possible:

1. Verify configuration: Check whether enable_jwt_auth: true is set. If JWT authentication is not enabled, the deployment is not affected regardless of version (NVD).

2. Disable OIDC userinfo caching: Set the cache TTL to 0 to disable the vulnerable cache, or disable JWT authentication entirely if operationally feasible (GHSA-jjhc-v7c2-5hh6). This eliminates the collision attack surface at the cost of increased OIDC provider lookup latency.

3. Monitor access logs: Audit LiteLLM access logs for anomalous session patterns where multiple distinct source IPs or user agents resolve to the same cached identity within short time windows (RAXE assessment).

Indicators of Compromise

Note: These indicators require application-level log instrumentation that may not be present in default LiteLLM configurations. The most reliable detection is version and configuration audit (RAXE assessment).

Strategic Context

This vulnerability highlights a recurring pattern in the AI infrastructure layer: authentication mechanisms added to AI gateway proxies and model-serving platforms are often implemented with performance optimisations (such as caching) that introduce subtle security weaknesses. The use of a truncated token as a cache key is a classic time-of-check/time-of-use design error that has well-documented precedents in session management literature (RAXE assessment).

LiteLLM occupies a growing niche as an AI gateway proxy, providing a unified API interface for organisations routing requests to multiple LLM providers. As AI gateway adoption increases, the authentication and access-control layers of these proxies become high-value targets. CVE-2026-35030 demonstrates that even when the vulnerable configuration is non-default, the severity of the bypass (complete identity hijack with no authentication required) warrants immediate attention for affected deployments (RAXE assessment).

The conditional scope of this vulnerability (requiring enable_jwt_auth: true) is a useful case study in risk communication. The CVSS 3.1 score of 9.1 reflects the worst-case impact once the prerequisite is met, but the practical risk to the broader LiteLLM user base is substantially lower because the prerequisite is not the default configuration. Organisations should assess their own exposure based on their deployment configuration rather than relying solely on the CVSS score (RAXE assessment).

Intelligence Tradecraft

Key Assumptions Checklist (KAC)

Source Grading (Admiralty Scale)

Access Tier

T1 (open source). All source material is publicly accessible. The NVD entry, GHSA advisory, and EPSS data are freely available without authentication.

Disclosure Credit

Vulnerability reported by veria-labs (GHSA-jjhc-v7c2-5hh6).

References

1. NVD: CVE-2026-35030 (CVSS 3.1: 9.1, CWE-287, Analyzed): https://nvd.nist.gov/vuln/detail/CVE-2026-35030
2. GHSA-jjhc-v7c2-5hh6: LiteLLM authentication bypass via OIDC userinfo cache key collision: https://github.com/BerriAI/litellm/security/advisories/GHSA-jjhc-v7c2-5hh6
3. FIRST.org EPSS: CVE-2026-35030 (score 0.00085, 24.6th percentile): https://api.first.org/data/v1/epss?cve=CVE-2026-35030