/
← Voltar ao feed
high

LiteLLM flaws CVE-2026-35029 and CVE-2026-59823 let low-privileged users take over AI gateways and steal provider API keys

1 fonte(s) · 1 atualização(ões) · publicado 13/10/2026 11:53 · coletado há 1 dia

Check Point Research disclosed two high-risk vulnerabilities in LiteLLM, the open-source AI gateway that sits between enterprise applications and providers such as OpenAI, Anthropic and Google. A user with minimal privileges could take full control of the gateway, read sensitive files, execute arbitrary code and harvest the provider API keys. LiteLLM is downloaded about 97 million times a month and is embedded in many other AI platforms, so some organisations may be running it without realising. Both flaws, CVE-2026-35029 and CVE-2026-59823, are fixed in version 1.83.9. The article does not report exploitation in the wild. The issues were reported to the maintainers through coordinated disclosure that began in October 2025.

Technical Details

  • CVE-2026-35029: the /config/update endpoint, which controls the proxy's runtime configuration, lacks a PROXY_ADMIN role check. Session tokens issued to any dashboard login belong to the "litellm-dashboard" team and are checked against a looser list of permitted UI routes that includes /config. Because the check uses prefix matching, any logged-in user can reach /config/update.
  • Tested against LiteLLM 1.77.7, the flaw enabled three outcomes: arbitrary file read, by injecting an environment variable that sets the dashboard logo path (for example /etc/passwd); takeover of the built-in admin account, by overwriting UI_USERNAME and UI_PASSWORD; and remote code execution, by registering a "pass-through endpoint" that loads a Python module from an attacker-controlled S3 or GCS bucket.
  • CVE-2026-59823: an SSRF in the "Clientside LLM Credentials" feature. An authenticated user can pass a user_config parameter to /chat/completions to create a router pointing at their own server. Requests, with the provider API keys attached, are then sent to the attacker. This path sidestepped existing restrictions on client-supplied api_base and api_key.
  • The researchers also found that password hashes were exposed to low-privileged users and stored unsalted with a single hash iteration. These issues duplicated an existing advisory.
  • Check Point stresses these are classic weaknesses (missing authorisation, SSRF, unsafe dynamic module loading). The risk comes from the gateway's position as a single point of compromise for an organisation's AI estate.

Remediation

  • Upgrade to LiteLLM 1.83.9 or later on every deployment, including instances embedded in other tools.
  • Audit gateway user accounts and remove those that are not needed.
  • Rotate AI provider API keys if there is any sign of unauthorised access before patching.
  • Test that limited roles are enforced in practice, not just on paper.
  • Bring LLM gateways into scope for regular security assessments.

Linha do tempo

  1. itsecurityguru.org ↗ · pub. 13/10/2026 11:53 · coletado 19/10 17:55 primeiro registro

    LiteLLM flaws CVE-2026-35029 and CVE-2026-59823 let low-privileged users take over AI gateways and steal provider API keys

    ler a análise desta fonte

    Check Point Research disclosed two high-risk vulnerabilities in LiteLLM, the open-source AI gateway that sits between enterprise applications and providers such as OpenAI, Anthropic and Google. A user with minimal privileges could take full control of the gateway, read sensitive files, execute arbitrary code and harvest the provider API keys. LiteLLM is downloaded about 97 million times a month and is embedded in many other AI platforms, so some organisations may be running it without realising. Both flaws, CVE-2026-35029 and CVE-2026-59823, are fixed in version 1.83.9. The article does not report exploitation in the wild. The issues were reported to the maintainers through coordinated disclosure that began in October 2025.

    Technical Details

    • CVE-2026-35029: the /config/update endpoint, which controls the proxy's runtime configuration, lacks a PROXY_ADMIN role check. Session tokens issued to any dashboard login belong to the "litellm-dashboard" team and are checked against a looser list of permitted UI routes that includes /config. Because the check uses prefix matching, any logged-in user can reach /config/update.
    • Tested against LiteLLM 1.77.7, the flaw enabled three outcomes: arbitrary file read, by injecting an environment variable that sets the dashboard logo path (for example /etc/passwd); takeover of the built-in admin account, by overwriting UI_USERNAME and UI_PASSWORD; and remote code execution, by registering a "pass-through endpoint" that loads a Python module from an attacker-controlled S3 or GCS bucket.
    • CVE-2026-59823: an SSRF in the "Clientside LLM Credentials" feature. An authenticated user can pass a user_config parameter to /chat/completions to create a router pointing at their own server. Requests, with the provider API keys attached, are then sent to the attacker. This path sidestepped existing restrictions on client-supplied api_base and api_key.
    • The researchers also found that password hashes were exposed to low-privileged users and stored unsalted with a single hash iteration. These issues duplicated an existing advisory.
    • Check Point stresses these are classic weaknesses (missing authorisation, SSRF, unsafe dynamic module loading). The risk comes from the gateway's position as a single point of compromise for an organisation's AI estate.

    Remediation

    • Upgrade to LiteLLM 1.83.9 or later on every deployment, including instances embedded in other tools.
    • Audit gateway user accounts and remove those that are not needed.
    • Rotate AI provider API keys if there is any sign of unauthorised access before patching.
    • Test that limited roles are enforced in practice, not just on paper.
    • Bring LLM gateways into scope for regular security assessments.