LiteLLM Flaws Enable Privilege Escalation and OIDC Authentication Bypass
LiteLLM fixed two high-severity vulnerabilities in version 1.83.0 that could allow attackers to gain elevated access in AI gateway deployments. CVE-2026-35029 stems from missing admin authorization on the /config/update endpoint, allowing an authenticated low-privilege user to change proxy settings and environment variables. The flaw could be abused to register attacker-controlled Python handlers for remote code execution, read arbitrary server files, and overwrite UI credentials to seize privileged accounts, creating broad confidentiality, integrity, and availability risk.
The same release also addressed CVE-2026-35030, an authentication bypass affecting LiteLLM deployments that enabled JWT-based authentication. In vulnerable versions, the platform used the first 20 characters of a token as the OIDC userinfo cache key, allowing a crafted token with a matching prefix to collide with a legitimate cached session and inherit that user’s identity and permissions. The issue is not enabled by default, limiting exposure to specific configurations, but together the flaws highlight significant access-control weaknesses in LiteLLM versions prior to 1.83.0.
Timeline
Apr 19, 2026
LiteLLM v1.83.7-stable adds command-execution fix and supply-chain hardening
LiteLLM released v1.83.7-stable with a security fix blocking arbitrary command execution via MCP stdio transport, along with hardening for proxy input validation, token lookup queries, file path resolution in skill archive extraction, and permission checks. The release also emphasized Docker image signature verification with cosign and pinned verification guidance to an immutable commit hash.
Apr 6, 2026
CVE-2026-35029 and CVE-2026-35030 are publicly disclosed
Public advisories disclosed two high-severity LiteLLM vulnerabilities: CVE-2026-35029, which lets a low-privilege authenticated user escalate privileges and potentially achieve remote code execution, and CVE-2026-35030, which allows authentication bypass in certain JWT-enabled deployments via cache key collisions.
Apr 6, 2026
LiteLLM fixes two vulnerabilities in version 1.83.0
LiteLLM released version 1.83.0 to fix two security flaws affecting earlier versions: an authorization bypass in the /config/update endpoint (CVE-2026-35029) and an OIDC userinfo cache key collision authentication bypass affecting JWT-enabled deployments (CVE-2026-35030).
Apr 1, 2026
LiteLLM ships nightly fix for CVE-2026-35029
BerriAI released LiteLLM v1.83.0-nightly with a fix for the broken access control flaw in the /config/update endpoint, later tracked as CVE-2026-35029. The vulnerability allowed low-privileged users to modify configuration and abuse pass-through features to exfiltrate environment variables and read files accessible to the application.
See the full picture in Mallory
Mallory subscribers get deeper analysis on every story, including:
Who’s affected and how
Deep-dive technical analysis
Actionable next steps for your team
IPs, domains, hashes, and more
Ask questions and take action on every story
Filter by topic, classification, timeframe
Get matching stories delivered automatically
Related Entities
Vulnerabilities
Organizations
Affected Products
Sources
Related Stories
Critical LiteLLM SQL Injection Exploited to Target Stored API Keys and Credentials
Attackers began exploiting **CVE-2026-42208** in LiteLLM shortly after public disclosure, using a pre-authentication SQL injection flaw in the product’s `Authorization: Bearer` verification path to query the backend PostgreSQL database without logging in. The vulnerability, also tracked as `GHSA-r75f-5x8p-qvmc`, affects LiteLLM versions **1.81.16 through 1.83.6** and was fixed in **v1.83.7** after the project replaced vulnerable string interpolation with a parameterized query. Sysdig said the first observed exploitation attempt arrived **36 hours and seven minutes** after the advisory was indexed, with activity focused on enumerating high-value tables holding virtual API keys, provider credentials, verification tokens, and environment-based configuration. Researchers described the intrusion attempts as targeted rather than opportunistic, citing knowledge of Prisma-generated PostgreSQL table names and `UNION`-based column discovery; while no confirmed follow-on abuse was observed, defenders are being urged to patch exposed instances immediately, rotate all stored secrets, and review logs and billing accounts for signs of compromise.
3 days ago
LMDeploy SSRF Was Exploited Within Hours as LiteLLM Proxy Disclosed RCE Chain
Attackers began exploiting **CVE-2026-33626** in LMDeploy less than 13 hours after public disclosure, using a server-side request forgery flaw in vision-language request handling to make inference servers fetch attacker-controlled and internal URLs. Sysdig said the bug affects LMDeploy `0.12.0` and earlier with vision-language support, where `image_url` input is not properly restricted, and observed an eight-minute attack against its honeypot that probed AWS instance metadata, localhost services, an unauthenticated administrative endpoint, and an out-of-band callback domain. The activity included scans of loopback ports associated with **Redis**, **MySQL**, and HTTP services, underscoring the risk of exposing AI inference infrastructure to internal network discovery and cloud credential theft. The disclosures also highlighted broader weaknesses in LLM-serving platforms. LiteLLM published three advisories for LiteLLM Proxy that researchers said can be chained to achieve **remote code execution**, including an unauthenticated SQL injection (`GHSA-r75f-5x8p-qvmc`), a server-side template injection flaw, and an authenticated command-execution issue in MCP stdio test endpoints. The affected LiteLLM range is `1.81.16` through `1.83.6`, with fixes available in `1.83.7-stable` and later, while LMDeploy users were urged to upgrade to `v0.12.3+`, enforce **IMDSv2**, restrict egress, rotate IAM credentials, and monitor inference hosts for requests to metadata, loopback, and private-network addresses.
1 weeks ago
LiteLLM Hit by PyPI Supply-Chain Compromise and Guardrail Sandbox Escape
Datadog Security Labs reported that the **TeamPCP** supply-chain campaign compromised the legitimate PyPI package **LiteLLM**, publishing malicious versions `1.82.7` and `1.82.8` that stole credentials, exfiltrated data, established persistence, and in some cases attempted to spread into Kubernetes environments. The campaign also hit **Telnyx** on PyPI and was linked to earlier compromises involving Trivy, npm packages, Aqua Security repositories, and Checkmarx tooling, with researchers concluding that stolen CI/CD and publishing credentials were reused across ecosystems. Datadog warned that LiteLLM `1.82.8` was especially dangerous because a malicious `.pth` file triggered payload execution when the Python interpreter started, while the Telnyx package executed code at import time and retrieved a second-stage payload hidden in a WAV file. Separately, X41 disclosed a high-severity **sandbox escape** in BerriAI LiteLLM affecting the `main-latest` Docker image, where authenticated users could reach arbitrary code execution through the `/guardrails/test_custom_code` API endpoint. The flaw relied on bypassing regex-based restrictions on custom Python guardrail code using string concatenation and CPython bytecode rewriting to recover unrestricted builtins and call `__import__`, allowing commands to run as the LiteLLM process user, which is **root** in the default Docker deployment. X41 assigned the issue **CWE-94** and a **CVSS 4.0 score of 8.7**, and Datadog advised organizations that installed the malicious LiteLLM releases to treat affected hosts and CI jobs as full credential-exposure events, rotate secrets, hunt for persistence and outbound traffic, and rebuild critical systems from known-good images rather than relying only on package rollback.
1 weeks ago