Loading vulnerability…
CVE-2026-35030 is an authentication bypass vulnerability in LiteLLM affecting versions prior to 1.83.0. In deployments where JWT authentication is enabled, the OIDC userinfo cache derives its cache key from only the first 20 characters of the presented token. Because JWTs generated with the same signing algorithm can share identical leading characters in their header portion, this truncated keying scheme can cause cache collisions between different tokens. An unauthenticated attacker can craft a token whose first 20 characters match those of a legitimate user token already present in the cache. If the cache lookup hits, LiteLLM associates the attacker with the cached userinfo for the legitimate user, resulting in impersonation and authorization under that user’s identity. The issue affects JWT/OIDC-enabled deployments and was corrected in LiteLLM 1.83.0.
Mallory correlates every CVE against your assets, your vendors, and active adversary campaigns. Know which vulnerabilities matter for you, not just which ones are loud.
What it means. What to do now. Patch path, mitigations, and the assume-compromise checklist.
What an attacker gets, and what they’ve been doing with it.
If you can’t patch tonight, do this now.
Patch, then assume compromise.
1 valid exploit after Mallory filtered fakes, detection scripts, and README-only repos.
This repository is a working Python PoC for CVE-2026-35030, an authentication bypass in BerriAI LiteLLM affecting versions prior to 1.83.0 when JWT/OIDC auth is enabled. The core issue is that LiteLLM caches OIDC userinfo using only the first 20 characters of the bearer token, which for RS256 JWTs are identical across different users because the JWT header is the same. The exploit demonstrates that if an admin's userinfo is cached first, a second JWT for an attacker can collide on the same cache key and inherit the admin identity. Repository structure is straightforward: `exploit/exploit.py` is the main entry point and performs either a collision demo or a full exploit attempt; `exploit/token_forge.py` obtains JWTs from the mock OIDC provider and analyzes their shared prefix; `oidc-provider/server.py` implements a FastAPI-based mock OIDC server with discovery, JWKS, userinfo, token issuance, and health endpoints; `docker-compose.yml` orchestrates PostgreSQL, the mock OIDC provider, a vulnerable LiteLLM instance on port 4000, and an optional fixed instance on port 4001; `litellm_config.yaml` enables JWT auth and points LiteLLM at the mock OIDC userinfo endpoint; the Dockerfiles pin vulnerable/fixed LiteLLM versions and patch enterprise checks for local reproduction. Main exploit capability: network-based auth bypass and privilege escalation via cache-key collision, not code execution. The exploit sends HTTP GET requests to LiteLLM `/user/info` with crafted bearer tokens after obtaining them from the mock OIDC `/token` endpoint. Success is determined by whether the attacker request receives `user_id=admin` or equivalent admin claims. The repository also includes a fixed-version comparison path showing that sha256-based cache keys prevent the collision.
Products and vendors Mallory has correlated with this vulnerability. Open in Mallory to drill down to specific CPE configurations and version ranges.
Vendor-confirmed product mapping. Mallory continuously reconciles this list against your asset inventory.
4 sources tracked across advisories, community write-ups, and news. New activity surfaces here as Mallory finds it.
Query your assets running an affected version, and investigate the blast radius.
Every observed campaign linking this CVE to a named adversary.
Malware families riding this exploit, with evidence and IOCs.
YARA, Sigma, Snort, and vendor rules, auto-deployed to your SIEM.
Cross-references every affected SKU, including bundled OEM variants.
Community discussion across Reddit, Mastodon, and other social sources.