When LLM Gateways Go Wrong: Findings from LiteLLM

Summary

A reported security assessment of LiteLLM 1.77.7 identified multiple high-severity weaknesses in the LLM gateway, with fixes reported in version 1.83.9. The central finding was a missing role-based authorization check on POST /config/update: a low-privileged authenticated user could modify proxy runtime configuration without holding the PROXY_ADMIN role. The supplied summary associates this flaw with CVE-2026-35029 and also lists CVE-2026-59823.^[0]

The configuration-access failure exposed several consequential capabilities. The summary reports arbitrary file reads through environment-variable injection, administrative account takeover by overwriting UI_USERNAME and UI_PASSWORD, and remote code execution by configuring pass-through endpoints to load Python modules from S3 or GCS. A separate Clientside LLM Credentials weakness allowed requests to be redirected to attacker-controlled infrastructure, potentially disclosing provider API keys.^[0]

This is a vulnerability-research and remediation account, not a documented attack campaign. The source reports coordinated disclosure and patching but supplies no observed exploitation, named threat actor, or attacker infrastructure. All technical details available here come from one secondary summary; the supplied evidence does not include the underlying research report or CVE-record contents for independent corroboration.^[0]

How it works

Authorization failure at the configuration boundary: POST /config/update reportedly validated a generic authenticated session without requiring PROXY_ADMIN. Consequently, an authenticated Internal User or another low-privileged account could change configuration intended for administrators, including environment variables and pass-through endpoint definitions. The described entry point required authentication; the evidence does not establish unauthenticated exploitation.^[0]

Environment and administrative credential manipulation: unauthorized configuration changes reportedly supported arbitrary file reads through environment-variable injection. The same configuration access allowed an attacker to overwrite UI_USERNAME and UI_PASSWORD to take over the administrative account. The supplied summary does not explain the underlying file-read primitive in sufficient detail to reconstruct that portion of the exploit.^[0]

Remote Python execution through pass-through configuration: an attacker could register a pass-through endpoint whose target referenced a Python file stored in S3 or GCS. LiteLLM would download the file and execute it using importlib's exec_module, including any top-level code and import-time side effects. Because the configuration endpoint lacked the administrator-role check, the source describes this route as reachable without first obtaining administrator privileges.^[0]

Nested configuration bypass in Clientside LLM Credentials: /chat/completions accepted a user_config parameter that could instantiate a new router with an arbitrary api_base. According to the summary, this route lacked validation and bypassed configurable_clientside_auth_params restrictions intended to prevent direct api_base and api_key overrides.^[0]

Provider-key exposure through request redirection: the arbitrary api_base allowed provider API traffic to be sent to a server controlled by the attacker. The source reports that the original provider API key could accompany the redirected request and be captured. This is presented as a separate server-side request forgery issue, rather than as a necessary step in the configuration-to-code-execution path.^[0]

Additional credential weakness and identifier limits: the assessment also reported exposed, weakly hashed password hashes, but the supplied summary provides no hashing algorithm or detailed exposure path. Although it names both CVE-2026-35029 and CVE-2026-59823, it explicitly maps only CVE-2026-35029 to the configuration authorization failure; it does not unambiguously assign the remaining findings to CVE-2026-59823.^[0]

Affected versions and patch status

Key takeaways

• The principal trust-boundary failure was allowing ordinary authenticated users to control administrator-level runtime configuration. In the reported implementation, that configuration included paths to credential changes and executable Python loading.^[0]
• The request-redirection finding demonstrates a separate validation gap: restrictions on direct credential and endpoint parameters were bypassed through nested router configuration supplied in user_config.^[0]
• Version 1.83.9 is the reported remediation point, but the available evidence is a single secondary summary. It supports prioritizing patching and targeted validation, not conclusions about active exploitation, attacker attribution, or compromise of a specific deployment.^[0]

Defensive actions

• Upgrade affected LiteLLM deployments to the reported fixed release, version 1.83.9.: The source identifies 1.83.9 as the release fixing the disclosed issues and describes the configuration authorization flaw as affecting earlier versions.^[0]
• Validate that POST /config/update rejects low-privileged authenticated accounts and requires the intended PROXY_ADMIN authorization.: The reported failure was not missing authentication, but acceptance of authenticated users without the administrator-role check. A test using a low-privileged account directly exercises that boundary.^[0]
• Validate Clientside LLM Credentials restrictions against nested user_config input, including attempts to set api_base through a newly instantiated router.: The reported SSRF bypass used user_config rather than a direct api_base or api_key override, so checking only the direct parameters would not exercise the described vulnerable path.^[0]
• When investigating suspected configuration abuse, inspect runtime settings for unauthorized UI_USERNAME or UI_PASSWORD changes, environment-variable modifications, and unexpected pass-through targets referencing Python modules in S3 or GCS.: These are the specific configuration surfaces associated with the reported administrative takeover, file-read, and code-execution capabilities. They are investigation targets, not supplied indicators of an observed compromise.^[0]
• If investigation confirms that provider requests were redirected to an unauthorized destination, replace the provider API keys carried by those requests.: The reported SSRF could deliver the original provider API key to the attacker-controlled destination. Credential replacement is therefore a response to confirmed exposure, not evidence that exposure occurred in any particular deployment.^[0]