LiteLLM: one key for secrets and sessions turns internal users into proxy admins

On 30 September 2026 BerriAI published advisory GHSA-7hp6-4w63-5g45 for the LiteLLM proxy, severity critical, CVSS 9.9. The proxy uses the same key, the salt key, for two jobs: it encrypts stored secrets with it and it mints session tokens with it. A signed-in user with the internal_user role can use this to become proxy_admin and then run arbitrary commands on the host through the MCP stdio endpoint. From version 1.91.0 this works in the default configuration. On 1 October BerriAI added GHSA-g5ff-637f-6q2m, CVSS 8.1, a local file read that exposes the master key.

How the escalation works

According to the advisory, the attacker requests a new API key and places a forged admin identity in a metadata field as the "secret". LiteLLM encrypts that value with the salt key and returns the result. When the attacker then sends the ciphertext as a bearer token, the proxy decrypts it with the same key, reads the admin identity and treats the request as coming from a proxy admin. With admin rights the MCP stdio endpoint is open, and through it the proxy starts processes on its own host.

The flaw is in the design. A key that encrypts data on behalf of users must never also vouch for identities, because any user who can get something encrypted ends up holding a valid token. The issue was reported by Hoa Nguyen of the OPSWAT Unit 515 team.

Affected versions and fixes

All figures come from the three advisories, retrieved through the GitHub API on 3 October 2026. The fixed versions were published as releases on 30 September.

The fixes for the critical flaw are spread across several release lines. Within each line, 1.101.0 to 1.101.2 are affected and 1.101.3 is not, and the same pattern holds for 1.102 and 1.103. Anyone running a version between 1.91.0 and 1.100.3 is exploitable in the default configuration. None of the pages read lists a CVE number, and no source reports attacks.

The second route to admin: /proc/self/environ

GHSA-g5ff-637f-6q2m needs even fewer rights. The /utils/transform_request endpoint had a blocklist for dangerous fields in the request body. It blocked vertex_credentials but missed the equivalent name vertex_ai_credentials. Through that field a file path reaches the Vertex AI credential loader, which reads the file and sends its content to a URL controlled by the attacker. BerriAI states that the internal_user_viewer role is enough, and many deployments hand that role to anyone who logs in through SSO.

Reading /proc/self/environ gives the attacker the environment variables of the proxy process, including LITELLM_MASTER_KEY and the API keys of the connected providers. With the master key the attacker is proxy admin. According to BerriAI there is no configuration switch against this path; it is fixed from 1.95.0.

The third advisory, GHSA-hhww-mrg2-969h, concerns /sso/debug/callback. The endpoint wrote identity provider fields unfiltered into a script block. A crafted display name runs script in the proxy origin as soon as a signed-in admin opens the link. Versions 1.65.5 up to before 1.85.0 are affected.

The upgrade trap

Anyone on a version before 1.91.0 without the experimental UI login enabled is not affected by the critical flaw, but is affected by the file read. Upgrading to 1.95.0 closes the file read and opens the admin takeover in the default configuration, because 1.95.0 lies in the range starting at 1.91.0. The upgrade target therefore has to be one of the five fixed versions for the critical flaw; all of them are above 1.95.0 and so carry both fixes.

As a stopgap the advisory names EXPERIMENTAL_UI_LOGIN=false. The switch disables the affected login path but costs CLI SSO and the Claude Code gateway login. It does nothing against the file read.

Where we stand

Our two LiteLLM gateways ran 1.89.4 on 3 October, EXPERIMENTAL_UI_LOGIN is not set, and the API port is bound to localhost only. The critical flaw does not reach this state, because 1.87.0 to 1.90.x are only exploitable with the switch set. The XSS affects only versions before 1.85.0. The file read from GHSA-g5ff-637f-6q2m does apply to 1.89.4, exploitable by anyone holding a key with internal_user_viewer. On the evening of 3 October we moved both to 1.100.4, one of the four lines with the fix for the critical advisory, which also carries the file-read fix from 1.95.0. More hardening points for the gateway are in the LiteLLM gateway security audit, and the setup itself is described in Our own AI pipeline with LiteLLM and vLLM.

If you run LiteLLM, first read the running version and compare it with the table. Then check who holds keys with internal_user or internal_user_viewer and whether SSO grants such roles automatically. After that, go straight to 1.100.4 or one of the other fixed versions, and rotate the master key if anyone with viewer rights had access whom you do not fully trust.

Further sources

• GHSA-7hp6-4w63-5g45, critical: admin takeover through the reused salt key
• GHSA-g5ff-637f-6q2m, high: local file read via vertex_ai_credentials
• GHSA-hhww-mrg2-969h, medium: reflected XSS in /sso/debug/callback
• LiteLLM release v1.100.4, one of the fixed versions from 30 Sep 2026
• Security audit of our LiteLLM gateway
• Our own AI pipeline with LiteLLM and vLLM