Check Point chains two LiteLLM proxy flaws: CVE-2026-35029 takes any login to admin and code execution, CVE-2026-59823 redirects calls. Upgrade to 1.83.9.
Check Point Research published a write-up on 13 October 2026 of two vulnerabilities in the LiteLLM proxy, the open source AI gateway that sits in front of LLM providers. The first, CVE-2026-35029, lets any authenticated user, including a low-privilege Internal User, rewrite proxy configuration and from there read files, take over the admin account and run code. The second, CVE-2026-59823, is a server-side request forgery (SSRF) that lets a caller with a valid virtual key steer the proxy's outbound request to a host of their choosing. Anyone running LiteLLM below 1.83.9 is affected by at least one of them. We found no report of exploitation in the sources we read.
Versions and scores: the dates differ from the headline
Check Point says the issues are "resolved as of" 1.83.9, but the two CVEs were fixed at different points.
- CVE-2026-35029: affects litellm below 1.83.0 and was fixed in 1.83.0, per the GitHub advisory GHSA-53mr-6c8q-9789. NVD published it on 6 April 2026 and scores it 8.8 High on CVSS 3.1 (AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H). GitHub's CVSS 4.0 score is 8.7.
- CVE-2026-59823: affects versions up to and including 1.83.8 and was fixed in 1.83.9, per GHSA-hx8v-g79f-8w5f. GitHub scores it 5.3 Medium on CVSS 4.0, with CWE-918. NVD listed it as awaiting analysis when we checked.
So the CVEs are not new: the first has been public since April. What is new is Check Point's analysis of how they chain. Check Point tested v1.77.7.
One flaw was public for six months before Check Point showed the chain.
The CVEs were public before Check Point showed how they chain.
CVE-2026-35029: missing admin check on /config/update
Per Check Point, the /config/update endpoint depends only on the generic user_api_key_auth check and never verifies the proxy admin role, unlike endpoints such as /invitation/new. UI logins produce a key tied to the litellm-dashboard team, and those tokens are routed through _is_ui_route(). That function matches routes with startswith against a list that includes /config, apparently meant for read access. /config/update starts with /config, so it passes for any valid UI session.
An attacker with that access can:
- Read arbitrary files. Set UI_LOGO_PATH through the environment variables setting and fetch the file via /get_image. Check Point's proof of concept read /etc/passwd.
- Take over the admin account. Overwrite UI_USERNAME and UI_PASSWORD, then log in at /login and receive the PROXY_ADMIN role.
- Run code. Register a pass-through endpoint whose target begins with s3:// or gcs://. The proxy downloads a Python file and executes it with importlib. The proof of concept created a marker file in /tmp; Check Point notes a reverse shell would work the same way.
Because the attacker needs a valid login, this is privilege escalation rather than an unauthenticated attack. On a gateway that issues keys or UI accounts to many developers or tenants, though, that bar is low.
CVE-2026-59823: SSRF through user_config
LiteLLM's is_request_body_safe check blocks api_base and base_url at the top level of a request body. It did not inspect the user_config object, which is used to build the outbound router. A caller with a valid virtual key can nest api_base inside user_config and send the proxy's request to an internal or external host, reaching endpoints the caller cannot otherwise access.
Check Point goes further: it says the redirected requests carry the proxy's configured provider API keys in default headers, so an attacker-run server can capture them. The GitHub advisory and NVD describe the SSRF but do not mention key capture, which is why the official score is Medium. Treat key theft as Check Point's finding, not as part of the CVE record.
Check Point also reported that password hashes are exposed to low-privilege users through the same UI-token weakness and are stored as a single unsalted hash iteration (GHSA-69x8-hrgq-fjj8, listed as a duplicate).
What defenders should do
- Upgrade LiteLLM to 1.83.9 or later. That covers both CVEs.
- If you cannot upgrade yet, note that GitHub says there is no configuration-level workaround for CVE-2026-35029; the advice is to restrict API key distribution.
- Review who holds virtual keys and Internal User accounts, and revoke any that are unused.
- Audit config changes and environment variables for unexpected UI_USERNAME, UI_PASSWORD or UI_LOGO_PATH values and for unfamiliar pass-through endpoints with s3:// or gcs:// targets.
- If an instance ran an affected version with untrusted users, rotate the provider API keys and admin credentials stored on it.
- Restrict the proxy's egress so it cannot reach internal services or arbitrary hosts.
Related coverage
Earlier ThreatFrontier articles on LiteLLM: CVE-2026-42208 pre-auth SQL injection, the salt-key admin forgery flaw, and chained Starlette and LiteLLM flaws.