A high-severity privilege escalation vulnerability in LiteLLM’s proxy configuration endpoint has put enterprise AI infrastructure at risk, allowing any authenticated user to achieve remote code execution, read arbitrary server files, and hijack privileged accounts, all without admin credentials.
LiteLLM is a widely deployed open-source AI gateway that serves as a unified proxy server, enabling developers and enterprises to call multiple LLM APIs, including OpenAI, Anthropic, and Google Gemini, in a standardized format.
As organizations rush to integrate large language models into production pipelines, LiteLLM has become foundational middleware for AI-driven infrastructure. This popularity makes any security flaw in the platform a high-impact event with a broad blast radius across the AI supply chain.
CVE-2026-35029: LiteLLM Vulnerability
Tracked as CVE-2026-35029 and disclosed under GitHub Security Advisory GHSA-53mr-6c8q-9789, the flaw resides in LiteLLM’s /config/update endpoint. The root cause is a missing authorization check: the endpoint responsible for modifying the proxy’s runtime configuration never validated whether the requesting user held the proxy_admin role.
Security researchers reported the issue, which was independently confirmed during a post-supply-chain-incident audit conducted and attributed to findings. The vulnerability affects all LiteLLM versions before1.83.0 and carries a CVSS v4 base score of 8.7 (HIGH) with the vector CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/SC:L/SI:L/SA:N.
The attack vector is network-accessible, has low attack complexity, and requires no user interaction; an attacker only needs a valid API key. Once authenticated, a low-privileged user can send a crafted POST request to /config/update and unlock four critical exploitation paths:
- Remote Code Execution (RCE): Register custom pass-through endpoint handlers pointing to attacker-controlled Python code, which the proxy then executes server-side
- Arbitrary File Read: Overwrite the
UI_LOGO_PATHconfiguration variable and retrieve sensitive server files through the/get_imageendpoint - Admin Account Takeover: Overwrite the
UI_USERNAMEandUI_PASSWORDenvironment variables, effectively hijacking the administrative dashboard account - Proxy Configuration Tampering: Modify runtime environment variables to redirect traffic, turn off security controls, or manipulate model routing logic
The confidentiality, integrity, and availability impact on the vulnerable system is rated High across the board, making this a near-complete system compromise for any exposed LiteLLM deployment.
A proof-of-concept exploit demonstrating broken access control on the config endpoint was published as an advisory SA-20260421-0, confirming the practical exploitability of the flaw.
CVE-2026-35029 did not emerge in isolation. It was discovered as part of a broader security audit triggered after a supply chain attack on March 24, 2026, in which LiteLLM versions 1.82.7 and 1.82.8 were compromised on PyPI for approximately 40 minutes.
The compromised packages contained malicious code injected via a poisoned Trivy dependency in LiteLLM’s CI/CD security scanning workflow. Most damaging was version 1.82.8, which added a malicious litellm_init.pth file to Python’s site-packages directory.
A location Python executes on every interpreter startup, meaning the malware fires during any Python command, not just LiteLLM imports. LiteLLM engaged Google’s Mandiant team for forensic analysis and completely rebuilt the release pipeline using isolated environments and ephemeral credentials before issuing the clean v1.83.0 release.
According to threat intelligence reports, CVE-2026-35029 was part of an attack chain that led to the breach of the AI hiring company, resulting in the exfiltration of 4 TB of data and the compromise of 33,185 unique secrets.
| Metric | Value |
|---|---|
| Attack Vector | Network |
| Attack Complexity | Low |
| Attack Requirements | None |
| Privileges Required | Low |
| User Interaction | None |
| Confidentiality (System) | High |
| Integrity (System) | High |
| Availability (System) | High |
| CVSS v4 Score | 8.7 HIGH |
Patch and Remediation
LiteLLM fixed CVE-2026-35029 in v1.83.0, released March 30, 2026. The patch enforces proxy_admin role validation on the /config/update endpoint, ensuring only authorized administrators can modify proxy configurations. Organizations running LiteLLM in production environments should upgrade immediately.
There is no configuration-level workaround; the only partial mitigation is restricting API key distribution to limit the pool of users who could exploit the flaw.
Security advisory also flags this vulnerability as a critical access control flaw affecting any authenticated user with proxy access. Given that a fresh LiteLLM vulnerability was reported as exploited shortly after disclosure in late April 2026, the attack surface around LiteLLM deployments remains actively targeted.
Security teams should immediately:
- Audit installed LiteLLM versions across local environments, Docker images, CI/CD pipelines, and deployment logs
- Upgrade to v1.83.0 or later, verified through the new CI/CD v2 pipeline with signed container images
- Review API key assignments and revoke access for any non-admin users who should not have proxy-level access
- Inspect
/config/updateaccess logs for unauthorized calls to the endpoint before patching - Run dependency risk scans tools like Snyk and runZero now flag versions below 1.83.0 as vulnerable
FAQ
Q1: Does CVE-2026-35029 affect unauthenticated users?
No exploitation requires a valid, authenticated API key for the LiteLLM proxy.
Q2: What is the patched version that fixes this privilege escalation vulnerability?
LiteLLM v1.83.0 fully patches CVE-2026-35029 by enforcing proxy_admin role authorization on /config/update.
Q3: Is there a configuration-level workaround available for CVE-2026-35029?
No configuration-level workaround exists; upgrading to v1.83.0 is the only definitive fix, with API key restriction as a partial mitigation.
Q4: Was this vulnerability actively exploited in the wild?
Yes, CVE-2026-35029 was chained in a supply chain attack linked to the Mercor breach, which exfiltrated 4 TB of data and 33,185 secrets.