CVE-2026-35030: 
NixOS vulnerability analysis and mitigation

CVE-2026-35030 is an authentication bypass vulnerability in BerriAI LiteLLM caused by an OIDC userinfo cache key collision. When JWT authentication is enabled (enable_jwt_auth: true), the cache uses only the first 20 characters of the JWT token (token[:20]) as the cache key, allowing an attacker to craft a token that collides with a legitimate user's cached entry. All LiteLLM versions prior to 1.83.0 are affected; the configuration is not enabled by default, so most instances are unaffected. It carries a CVSS v3.1 score of 9.1 (Critical) and a CVSS v4.0 score of 9.4 (Critical) (GitHub Advisory). IBM Observability with Instana (OnPrem) is also listed as an affected product (IBM Advisory). The advisory was published on April 3, 2026, and the CVE was published to NVD on April 6, 2026.

The root cause is classified as CWE-287 (Improper Authentication): the OIDC userinfo cache key is derived from only the first 20 characters of the JWT token string (token[:20]) rather than a full cryptographic hash (GitHub Advisory). Because JWT headers produced by the same signing algorithm share an identical structure, their base64-encoded representations produce the same leading characters, making collisions predictable and achievable without cryptographic attack. An unauthenticated remote attacker can craft a JWT token whose first 20 characters match those of a token belonging to a legitimate, cached user; upon a cache hit, the attacker's request is resolved with the victim's identity and permissions. Exploitation requires that the target deployment has explicitly enabled enable_jwt_auth: true and that a legitimate user's token is present in the OIDC userinfo cache (GitHub Advisory). A PoC repository has been published at github.com/learner202649/CVE-2026-35030-PoC and referenced on Sploitus (Feedly).

Successful exploitation allows an unauthenticated attacker to fully impersonate a legitimate user, inheriting their identity and all associated permissions within the LiteLLM deployment. This results in high confidentiality and integrity impact — the attacker can access sensitive data, issue API requests to backend LLM providers, and potentially manipulate model routing or billing configurations on behalf of the victim. Availability is not directly impacted by this vulnerability. Downstream systems connected through LiteLLM (e.g., LLM provider APIs, internal tooling) may also be exposed if the impersonated user holds elevated privileges (GitHub Advisory).

A PoC exploit has been published on GitHub (github.com/learner202649/CVE-2026-35030-PoC) and indexed on Sploitus, indicating public weaponization of the vulnerability (Feedly). As of the time of reporting, there is no confirmed evidence of active in-the-wild exploitation or threat actor attribution. The EPSS score is approximately 0.062% (roughly the 15th percentile), suggesting a currently low but non-negligible probability of exploitation in the near term (GitHub Advisory). The vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog.

1. Reconnaissance: Identify LiteLLM deployments (version < 1.83.0) that have enable_jwt_auth: true configured, using network scanning tools or by probing API endpoints for JWT-based authentication challenges.
2. Obtain a sample token prefix: Observe or infer the first 20 characters of a JWT token issued by the target's signing algorithm (e.g., by registering a low-privilege account or intercepting a token in transit). JWT headers for the same algorithm (e.g., HS256) produce identical base64-encoded prefixes.
3. Craft a collision token: Construct a JWT token whose first 20 characters (token[:20]) exactly match those of a legitimate user's token that is expected to be present in the OIDC userinfo cache. The remainder of the token does not need to be valid.
4. Submit the crafted token: Send an API request to the LiteLLM endpoint with the crafted token in the Authorization: Bearer header.
5. Achieve authentication bypass: If the cache contains an entry keyed on the matching 20-character prefix, the server returns the cached userinfo for the legitimate user, granting the attacker that user's identity and permissions without valid credentials (GitHub Advisory).

• Network: Unexpected API requests to LiteLLM endpoints using JWT tokens that are structurally valid in their first 20 characters but contain invalid or malformed payloads/signatures; repeated authentication attempts from unfamiliar IP addresses.
• Logs: LiteLLM access logs showing successful authenticated requests from IP addresses not associated with the legitimate token owner; cache hit events for OIDC userinfo where the requesting IP differs from the original token issuer.
• Behavioral: API calls made under a legitimate user's identity at unusual times or from unusual geographic locations; unexpected LLM provider API usage spikes attributed to a specific user account that the user did not initiate.

Upgrade LiteLLM to version 1.83.0 or later, where the OIDC userinfo cache key uses the full cryptographic hash of the JWT token instead of the truncated token[:20] prefix (GitHub Advisory). If immediate patching is not feasible, two workarounds are available: (1) disable OIDC userinfo caching by setting the cache TTL to 0, or (2) disable JWT authentication entirely (enable_jwt_auth: false) until the patch can be applied. IBM Instana OnPrem users should consult the IBM security bulletin for applicable remediation guidance (IBM Advisory).

A technical write-up was published on Dev.to by Armor1AI discussing the JWT cache failure mechanism and credential rotation procedures following exploitation (Dev.to Article). IBM issued a security bulletin acknowledging the vulnerability's impact on IBM Observability with Instana OnPrem (IBM Advisory). The vulnerability was noted on Bluesky via the CVE tracking account, and indexed by multiple vulnerability aggregators shortly after disclosure.