CVE-2026-35030: BerriAI litellm · Improper Authentication
Affects BerriAI litellmSource CVE Database V5
Not known to be exploited · CVSS 9.4 Critical : upgrade to 1.83.0 as a priority.
Data as of 29 Oct 2026, 19:04 UTC
Contested
Critical score, yet low EPSS after six months- EPSS
- 0.6% chance of exploitation in 30 days – higher than 49% of CVEsExploit Prediction Scoring System: the likelihood attackers will use this flaw soon.
- Patch
- Available – fixed in 1.83.0
CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:H/VA:N/SC:H/SI:H/SA:NExploitation evidence
Disclosed: evidence found.
CVE published 6 Apr 2026
Detectable: no evidence on record.
No public nuclei template indexed
Weaponized: evidence found.
Public exploit code: GitHub proofs of concept
Exploited in the wildExploited: no evidence on record.
Not in CISA KEV and no source reports exploitation
Observed by OffSeq MirageSeen by Mirage: no evidence on record.
No attack traffic recorded by OffSeq Mirage sensors
A missing step is not evidence of safety. Sources: cve.org (opens in a new tab), GitHub proofs of concept, the Metasploit, Exploit-DB and nuclei-templates index as of 29 Oct 2026.
What to do
Upgrade litellm and berriai/litellm to 1.83.0.
Affected software
| Product | Affected | Fixed in |
|---|---|---|
| BerriAIlitellm | Affected
| Fixed in
|
GitHubberriai/litellmpkg:github/berriai/litellmOther threats | Affected
| Fixed in
|
Check your own hosts for these packages with threat-finder (opens in a new tab), our free open-source scanner.
AI-suggested
A fixed version, litellm 1.83.0, is available and should be applied to remediate this vulnerability. Deployments that do not have JWT/OIDC authentication enabled are not affected. Patch status is confirmed by the vendor advisory. Users should upgrade to version 1.83.0 or later to resolve this issue.
Description
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.
References
- github.com/BerriAI/litellm/security/advisories/GHSA-jjhc-v7c2-5hh6 (opens in a new tab)
- access.redhat.com/security/cve/CVE-2026-35030 (opens in a new tab)
- bugzilla.redhat.com/show_bug.cgi?id=2455509 (opens in a new tab)
- security.access.redhat.com/data/csaf/v2/vex/2026/cve-2026-35030.json (opens in a new tab)
- access.redhat.com/errata/RHSA-2026:13545 (opens in a new tab)
- access.redhat.com/errata/RHSA-2026:28960 (opens in a new tab)
- access.redhat.com/errata/RHSA-2026:30056 (opens in a new tab)