CVE-2026-35030: BerriAI LiteLLM authentication bypass via OIDC cache key collision

CVE-2026-35030 · Severity: critical · CVSS 9.1 · Published 2026-04-06

LiteLLM, a tool used to manage and proxy requests to various Artificial Intelligence (AI) models, contains a security flaw in how it handles user authentication. When specific security settings are enabled, the system fails to uniquely identify users, allowing an attacker to potentially impersonate a legitimate user. If successfully exploited, an attacker could gain unauthorized access to AI services and sensitive data, inheriting the permissions of the person they are impersonating.

Technologies: Berriai LiteLLM, litellm (PyPI), Red Hat Lightspeed Core. Vendors: Berriai, PyPI, Red Hat.

Quick answers

Is CVE-2026-35030 exploited in the wild?
No. Junglewise Threat Intelligence has no report of CVE-2026-35030 being exploited in the wild.
How severe is CVE-2026-35030?
Critical severity, with a CVSS score of 9.1, published 6 April 2026.
Which products and versions are affected?
Berriai LiteLLM < 1.83.0; litellm (PyPI) ECOSYSTEM:introduced=0,fixed=1.83.0.
Is there a fix for CVE-2026-35030?
Yes. litellm (PyPI): upgrade to 1.83.0 or later. Junglewise finds every place you run it, drafts the upgrade and applies it once you approve.
How is CVE-2026-35030 attacked?
It is attacked over the network, in a software library.
Am I affected by CVE-2026-35030?
Check whether you run Berriai LiteLLM, litellm (PyPI) or Red Hat Lightspeed Core at an affected version. Junglewise does that check for you around the clock: connect your code, cloud and domains, and it matches new vulnerabilities like this one against what you actually run and tells you when one reaches you.

How to fix

  • litellm (PyPI): upgrade to 1.83.0 or later
    pip install "litellm>=1.83.0"

Technical details

LiteLLM prior to version 1.83.0 is vulnerable to an authentication bypass when `enable_jwt_auth` is set to true. The root cause is that the OIDC userinfo cache uses only the first 20 characters of a JWT token as its cache key. Because JWT headers using the same signing algorithm often share the same initial 20 characters, this leads to a cache key collision. An unauthenticated remote attacker can craft a JWT that matches the prefix of a legitimate user's cached token. Upon a cache hit, the attacker is granted the identity and permissions of the legitimate user. The issue is resolved in v1.83.0 by using a full hash of the JWT as the cache key.

Affected products

  • BerriAI litellm < 1.83.0
  • Red Hat Red Hat Ansible Automation Platform 2.6 2.6
  • Red Hat Red Hat OpenShift AI 2.25 2.25
  • Red Hat Red Hat OpenShift AI 3.3 3.3
  • Red Hat Lightspeed Core

Identifiers

  • CVE-2026-35030
  • GHSA-jjhc-v7c2-5hh6
  • PYSEC-2026-390

Timeline

  • 2026-04-03: advisory: GitHub Advisory GHSA-jjhc-v7c2-5hh6 published
  • 2026-04-06: disclosed: CVE-2026-35030 published
  • 2026-05-04: patched: Red Hat released security updates for Ansible Automation Platform

References

This page as Markdown. Free to reuse under CC BY 4.0 with a link back.