Check Point Maps How a Low-Privilege LiteLLM Login Became Gateway RCE and Key Theft
On October 13, 2026, Check Point Research published its full write-up of CVE-2026-35029 and CVE-2026-59823 in LiteLLM Proxy, both fixed by 1.83.9, showing config-update privilege gaps and user_config SSRF against provider keys.
Check Point Research published a full technical walk-through on October 13, 2026 of two LiteLLM Proxy flaws that turn a routine authenticated session into gateway takeover and provider-key theft. The CVEs are not brand-new filings—CVE-2026-35029 landed in NVD in April 2026 and CVE-2026-59823 in September—but the October 13 research post is the first public end-to-end narrative of how the bugs chain in a live gateway. Both issues are fixed in LiteLLM 1.83.9 and later. Current upstream tags are already past 1.105, so the operational message is audit and upgrade, not wait for a patch.
LiteLLM sits between applications and model providers. It stores API keys, enforces roles, routes prompts and tracks spend. The GitHub repository BerriAI/litellm holds more than 61,000 stars. Check Point Research assessed version 1.77.7 and says both named CVEs are resolved as of 1.83.9.
The missing admin gate on /config/update
CVE-2026-35029 is tracked as GitHub advisory GHSA-53mr-6c8q-9789. NVD scores it CVSS 3.1 8.8 High (AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H). The first patched release on the advisory is 1.83.0. The root cause is straightforward: POST /config/update depended on generic user_api_key_auth and never checked that the caller held PROXY_ADMIN, unlike hardened admin routes such as invitation creation.
A second defect widened who could reach that route. UI login mints a temporary key tagged with the litellm-dashboard team. Tokens with that team are classified as UI tokens and evaluated against a permissive ui_routes list that includes the prefix /config. Because the matcher uses startswith, /config/update matched the read-oriented /config entry. Any user with a valid UI session—including an Internal User—could therefore call the configuration update endpoint.
From there, Check Point Research shows three concrete impacts that share the same write primitive. Injecting environment_variables updates os.environ. Setting UI_LOGO_PATH to a local path and fetching /get_image returns arbitrary files the process can read. Overwriting UI_USERNAME and UI_PASSWORD lets the attacker log into the dashboard as Proxy Admin. Registering a pass-through endpoint whose target begins with s3:// or gcs:// causes LiteLLM to download a Python module and execute it through importlib during adapter load—remote code execution on the gateway host.
SSRF that walks around the api_base blocklist
CVE-2026-59823 is GHSA-hx8v-g79f-8w5f. NVD and GitHub score it CVSS 4.0 5.3 Medium under CWE-918. The fixed release is 1.83.9. LiteLLM already blocked top-level api_base and base_url through is_request_body_safe and related client-side credential controls. The bypass nests api_base inside a user_config object. When that field is present, the proxy builds a fresh litellm.Router from the attacker-controlled config and sends the completion to the attacker’s host. The outbound request can carry provider credentials the virtual-key holder was never meant to see.
Check Point Research’s October 13 company summary frames the pair the same way: low-privileged authenticated access reaches administrative configuration, and a separate SSRF path steals AI provider API keys. The research post’s TL;DR states both are resolved in 1.83.9.
Why a patched gateway still belongs in this morning’s cyber desk
These are not zero-days against current mainline tags. They are a public reconstruction of how an LLM gateway’s trust boundaries failed when role checks were incomplete and when a documented “clientside credentials” feature took a different code path than the body allowlist. That combination matters because LiteLLM is often embedded inside other products, not only run as a named service. Teams that pinned versions months ago, or that inherit LiteLLM through an agent platform, may still be below 1.83.9 even while GitHub’s latest release line sits in the 1.10x range.
The mitigation path is unambiguous. Upgrade every LiteLLM Proxy deployment to 1.83.9 or newer—ideally current stable—then rotate provider keys if the gateway was reachable by untrusted authenticated users before the bump. Re-check that non-admin roles cannot hit configuration mutation routes in practice, not only in documentation. Inventory indirect installs where LiteLLM ships inside another stack.
For AI infrastructure security, the October 13 disclosure is useful less as a panic patch and more as a concrete map: the same classes of bugs that have haunted traditional admin panels—missing function-level authorization, prefix-matched route allowlists, dynamic module loads from cloud storage, and SSRF beside credential stores—now sit in front of billable model APIs. Gateways that hold every provider key need the same scrutiny as any other secret-bearing reverse proxy.
- #LiteLLM
- #CVE-2026-35029
- #CVE-2026-59823
- #LLM Gateway
- #Check Point Research
Author
Raj M
Contributor
AI Systems Architect is a seasoned technology leader with over 15 years of experience in the IT industry working with Fortune 500 companies. With a solid foundation in multi-agent systems, open-source LLM infrastructure, and enterprise deployment, he excels at building scalable production-grade AI platforms.