One Missing Role Check, Three Ways to Own the Gateway: Check Point’s LiteLLM Chains

2026-10-13 AI Vulnerabilities & CVEs by al-ice.ai Editorial

On 13 October 2026, Check Point Research published a security assessment of LiteLLM — the open-source LLM gateway that sits between enterprise applications and providers such as OpenAI, Anthropic and Google, and that secondary coverage puts at roughly 97 million downloads a month. Assessed at version 1.77.7, the gateway yielded two CVEs that chain into full compromise: CVE-2026-35029, a missing authorization check on the /config/update endpoint, and CVE-2026-59823, an SSRF via the user_config request parameter. Both are resolved as of version 1.83.9. Check Point demonstrated file access, credential theft, administrative takeover and remote code execution in a controlled environment.

The CVEs themselves are not both new — and that is part of the story. CVE-2026-35029 has carried an NVD record since April 2026; CVE-2026-59823 since mid-September. What is new is the published exploit engineering: three distinct compromise paths through a single unguarded endpoint, plus a second SSRF in the feature that handles client-side provider credentials. For anyone running an LLM gateway, the gateway holds every provider key in the estate, so “low-privileged user can reconfigure the proxy” cashes out as “low-privileged user can take the keys.”

The missing check, and the startswith that widened it

The assessment’s central mechanism deserves to be read carefully, because it is two defects composed. First, the update_config handler for POST /config/update depends only on the generic user_api_key_auth dependency and never checks for the PROXY_ADMIN role — unlike neighbouring admin endpoints such as /invitation/new, which perform the role check explicitly. Any authenticated caller passes.

Second, the route allowlist that was supposed to limit UI-session tokens widens the hole instead of containing it. Tokens minted at UI login carry the special litellm-dashboard team ID; authorization classifies them as “ui” tokens on that basis alone and routes them to a permissive _is_ui_route check. That check matches with startswith against a list that includes /config — presumably intended to allow read-only configuration access — so /config/update satisfies it. Every user with a valid UI session, down to the baseline Internal User role, can rewrite the proxy’s runtime configuration: environment variables, model lists, pass-through endpoints.

Three paths from one endpoint

From that single primitive, Check Point documents three impacts, each with a working proof-of-concept:

Arbitrary file read. The endpoint accepts an environment_variables map that is decrypted into os.environ. Setting UI_LOGO_PATH — the file path served verbatim by the unauthenticated /get_image logo endpoint — to /etc/passwd returns the file’s contents. Any file the LiteLLM process can read, including configuration and secrets, is retrievable the same way.
Administrative account takeover. The UI login flow authenticates against the UI_USERNAME and UI_PASSWORD environment variables, and a credential match grants full PROXY_ADMIN. Overwriting both through the same injection, then logging in with the new values, yields the built-in admin account — and with it, every provider credential the gateway holds.
Remote code execution. LiteLLM’s pass-through endpoints accept a target that may reference a Python adapter module on remote storage. A target of the form s3://attacker-bucket/adapters/evil_adapter.proxy_handler_instance causes the gateway to download and execute the attacker’s module. Low-privileged user in, arbitrary command execution out.

The assessment adds two password-handling findings in the same area: the proxy exposes password hashes through API endpoints to callers who should never see them, and the hashes themselves are a single iteration of a standard unsalted hash — no bcrypt, scrypt or Argon2 — leaving any exposed material open to fast offline cracking. Two related GHSA records are marked duplicates in the write-up.

The second CVE: the guard that checked two keys out of three

CVE-2026-59823 is the smaller, cleaner defect, and the more generalisable one. LiteLLM Proxy validates request bodies with is_request_body_safe, which blocks the api_base and base_url parameters — but does not inspect user_config. Since user_config is used to construct the outbound router for a request, an authenticated caller with a valid virtual key can nest an api_base inside it and redirect the proxy’s server-side request to an internal or external host of their choosing, reaching endpoints the caller could not otherwise access. The vendor advisory (GHSA-hx8v-g79f-8w5f, severity medium) gives the range as <=1.83.8 with 1.83.9 as the patch; exploitation requires a valid virtual key, which bounds the exposure to callers the operator already admitted — still, in a gateway, “admitted caller” routinely includes every application team in the company.

Note the shape both defects share with findings elsewhere on this site: a control that inspects the top level while the dangerous value arrives nested one layer down. LiteLLM’s body guard checked two parameter names and missed the object that carries them; SAP’s tenant validator, patched the same day, covered three call sites while the fourth interpolated the same string into a token URL for another month. Enumerating every path a value can take to a sink is the whole job, and partial enumerations keep producing CVEs.

What to do

Upgrade to LiteLLM 1.83.9 or later. That version closes the user_config SSRF; the /config/update authorization flaw predates it (fixed in the 1.83.0 line), so anything older than 1.83.0 carries the full chain. Confirm the running version, not the pinned one — gateways are long-lived processes.
Rotate everything the gateway touches. Provider API keys, the master key, UI_USERNAME/UI_PASSWORD, and any virtual keys issued before the upgrade. The takeover paths are credential-rewriting attacks; a quiet compromise leaves the configuration looking normal with attacker-known secrets.
Restrict who can reach /config/update at the network layer. Configuration-write endpoints on AI infrastructure should not be reachable from the same network segment as ordinary API consumers. An egress and ingress policy around the gateway covers this finding and the next one shaped like it.
Audit pass-through endpoints and custom adapters. Any target pointing at remote storage (s3://, gcs://) is remote code execution by design — useful, and exactly as dangerous as it sounds. Inventory them; require change control on them.
For gateway operators generally: treat the LLM gateway as a credential store with a request router attached. That is what it is. It deserves the same controls as a secrets manager — which is also why the agent-gateway credential-disclosure cluster and the Poellm botnet’s abuse of LiteLLM infrastructure keep recurring in this category.

Verification note. The Check Point Research write-up (“When LLM Gateways Go Wrong”, dated 13 October 2026 on the page) was fetched and read first-hand; all mechanism descriptions, code excerpts, line-number references and proof-of-concept flows above are carried from that assessment, not reproduced from it, and no proof-of-concept was executed by us. CVE-2026-35029’s record (published April 2026) and CVE-2026-59823’s record (published 16 September 2026, Awaiting Analysis, CWE-918, fix commit and PR references) were read first-hand from the NVD 2.0 API; the GHSA-hx8v-g79f-8w5f range (<=1.83.8, patched 1.83.9, medium) and its user_config analysis were read first-hand from the GitHub advisory API; the current PyPI latest (1.105.0) was read from the registry. The download-volume figure and provider list are carried from secondary coverage and labelled as such. LiteLLM was not installed, no gateway was started, and no request was sent to any third-party deployment. The scoring and remediation commentary is our editorial analysis. We have no evidence of in-the-wild exploitation of these chains and imply none.

Sources: