A security assessment of LiteLLM version 1.77.7, a popular open-source LLM gateway, uncovered multiple high-severity vulnerabilities tracked as CVE-2026-35029 and CVE-2026-59823, fixed in version 1.83.9. The core issue was a missing role-based access control check on the /config/update endpoint, which let any authenticated user, even low-privileged ones, modify the proxy's runtime configuration. This enabled arbitrary file reads via environment variable injection, administrative account takeover by overwriting UI_USERNAME/UI_PASSWORD, and remote code execution through malicious Python modules loaded from S3 or GCS via pass-through endpoints. A separate SSRF flaw in the Clientside LLM Credentials feature let attackers redirect API calls to exfiltrate provider keys. Additional weaknesses included exposed, weakly-hashed password hashes. All issues were disclosed through coordinated disclosure and patched.
Table of contents
TL;DR;IntroductionAccess Control Bypass in /config EndpointServer-Side Request Forgery Leading to LLM Provider API key ExtractionMiscellaneous VulnerabilitiesAssigned CVEsConclusionsQuestions this post answers
What is CVE-2026-35029 in LiteLLM and how does it work?
CVE-2026-35029 is a missing authorization check on the POST /config/update endpoint in LiteLLM versions before 1.83.9, including the tested 1.77.7. Because the endpoint only verified a generic authenticated session rather than checking for the PROXY_ADMIN role, any authenticated user, including low-privileged Internal User accounts, could modify the proxy's runtime configuration, including environment variables and pass-through endpoints. Teams running LLM gateways can track emerging CVEs like this one on daily.dev before they hit production.
How can attackers achieve remote code execution through LiteLLM's pass-through endpoints feature?
Attackers exploit the /config/update endpoint by registering a pass-through endpoint whose target parameter points to an s3:// or gcs:// URL. LiteLLM downloads the referenced Python file and executes it via importlib's exec_module, running any top-level code including import-time side effects, giving an attacker full code execution on the gateway host without needing admin privileges first. Developers securing AI infrastructure can follow writeups like this on daily.dev to catch dynamic-loading risks early.
How does the LiteLLM Clientside LLM Credentials feature create an SSRF vulnerability?
The /chat/completions endpoint accepts a user_config parameter that lets a caller instantiate a new router with an arbitrary api_base URL, with no validation applied. This bypasses the configurable_clientside_auth_params restrictions meant to block direct api_base and api_key overrides, letting an attacker redirect LLM API calls to a server they control and capture the original provider API key in transit. Anyone evaluating LLM gateway security can use coverage like this on daily.dev to weigh SSRF exposure before adoption.
Share this post