GHSA-JJHC-V7C2-5HH6

Vulnerability from github – Published: 2026-04-03 21:59 – Updated: 2026-04-06 23:40
VLAI
Summary
LiteLLM: Authentication bypass via OIDC userinfo cache key collision
Details

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.

Severity
9.4 (Critical)
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
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "litellm"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.83.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-35030"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-287"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-04-03T21:59:50Z",
    "nvd_published_at": "2026-04-06T17:17:12Z",
    "severity": "CRITICAL"
  },
  "details": "###  Impact\n\nWhen 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.\n\nThis configuration option is not enabled by default. **Most instances are not affected.**\n\nAn unauthenticated attacker can craft a token whose first 20 characters match a legitimate user\u0027s cached token. On cache hit, the attacker inherits the legitimate user\u0027s identity and permissions. This affects deployments with JWT/OIDC authentication enabled.\n\n###  Patches\n\nFixed in v1.83.0. The cache key now uses the full hash of the JWT token.\n\n###  Workarounds\n\nDisable OIDC userinfo caching by setting the cache TTL to 0, or disable JWT authentication entirely.",
  "id": "GHSA-jjhc-v7c2-5hh6",
  "modified": "2026-04-06T23:40:39Z",
  "published": "2026-04-03T21:59:50Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/BerriAI/litellm/security/advisories/GHSA-jjhc-v7c2-5hh6"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-35030"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/BerriAI/litellm"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "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",
      "type": "CVSS_V4"
    }
  ],
  "summary": "LiteLLM: Authentication bypass via OIDC userinfo cache key collision"
}


Log in or create an account to share your comment.




Tags
Taxonomy of the tags.





Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.

Sightings

Author Source Type Date Other

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or observed by the user.
  • Confirmed: The vulnerability has been validated from an analyst's perspective.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
  • Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
  • Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
  • Not confirmed: The user expressed doubt about the validity of the vulnerability.
  • Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.


Detection rules are retrieved from Rulezet.