A 9.9-rated GitHub advisory says LiteLLM's reused salt key lets an internal user become proxy admin and run commands. Two CVEs and another advisory landed too.
LiteLLM's maintainers published a critical advisory on 30 September 2026 for the open-source LLM proxy. A single encryption key, the salt key, is used for two jobs, and that lets an ordinary authenticated user mint their own proxy admin session. GHSA-7hp6-4w63-5g45 is rated 9.9 (CVSS 3.1) in the GitHub advisory and has no CVE assigned as of this writing. Two CVEs and a second GitHub advisory landed within the same week, so anyone running a LiteLLM gateway has several upgrades to check.
TF covered an earlier set of LiteLLM bugs in the Starlette and LiteLLM gateway chain. This story is separate.
GHSA-7hp6-4w63-5g45: cross-domain reuse of the salt key
The advisory is titled "Privilege Escalation to Proxy Admin via Cross-Domain Reuse of the Salt Key." Its vector is CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H. The advisory page labels this a CVSS v3 base score and does not name the scorer. The weaknesses listed are CWE-269, CWE-345 and CWE-441 (confused deputy).
The advisory's own summary is that the proxy uses one encryption key for two purposes: sealing secrets at rest and minting session tokens. An internal user can craft metadata containing forged admin credentials. The proxy encrypts that data, and later decrypts it when it is presented as a bearer token. The proxy then treats the bearer as an administrator, which per the advisory includes the ability to execute arbitrary commands through the MCP stdio endpoint.
The only precondition is an existing internal_user account. The affected releases from 1.91.0 are exploitable in the default configuration. Versions 1.87.0 through 1.90.x are exploitable only when EXPERIMENTAL_UI_LOGIN=true was explicitly set. Credit goes to Hoa X. Nguyen of OPSWAT Unit 515 for discovery, and to Haruna38 as reporter.
Affected and fixed versions
| Affected (fixed version excluded) | Fixed |
|---|---|
| 1.91.0 to before 1.100.4 | 1.100.4 |
| 1.101.0 to before 1.101.3 | 1.101.3 |
| 1.102.0 to before 1.102.2 | 1.102.2 |
| 1.103.0 to before 1.103.1 | 1.103.1 |
| 1.104.0rc1 to before 1.104.0rc2 | 1.104.0rc2 |
Each fixed version is the first release in its line that is not affected, so a release below it on the same line is vulnerable. Pick the patched release that matches the branch you run.
The advisory lists one workaround: set EXPERIMENTAL_UI_LOGIN=false. That setting disables CLI SSO and the Claude Code gateway login, so it breaks those flows. It is a stopgap and not a substitute for upgrading.
CVE-2026-93355: JWT email fallback account takeover
NVD published this record on 28 September 2026 from VulnCheck, and it is still awaiting analysis. LiteLLM's JWT authentication falls back to an email lookup without checking the email_verified claim. An attacker holding a valid JWT from the configured identity provider can present a token with an unverified email that matches a victim's account. The attacker inherits the victim's role, including proxy_admin, and overwrites the victim's stored identity binding, which keeps the access.
VulnCheck, the CNA for the record, scores it 8.1 under CVSS 3.1 and 7.6 under CVSS 4.0. CISA's SSVC entry of 29 September records a proof of concept and total technical impact, with automatable set to no. NVD and VulnCheck list versions up to and including 1.102.1 as affected and do not state a fixed version. Ox Security's write-up, which says it disclosed publicly on 29 September after reporting the bug on 18 May and getting no reply to a 27 July follow-up, gives different numbers: affected through 1.100.1 and a CVSS 3.1 score of 8.8. We could not reconcile them. Neither NVD nor VulnCheck names a fixed version, and we have not found one. Treat 1.102.1 as the safer bound and check LiteLLM's release notes before relying on any specific fix.
CVE-2026-89032: semantic cache crosses tenants
NVD published this on 25 September 2026. A metadata key mismatch between _get_semantic_cache_tenant_scope() and _get_metadata_variable_name() breaks tenant isolation in the semantic cache. A user with a valid virtual key can send semantically similar prompts on routes such as /v1/responses and /bedrock/* and read other tenants' cached responses. The record says this can expose personal data, financial data or source code. It can also cause agentic front-ends to auto-execute attacker-supplied tool calls under victim credentials, when a cached function_call or tool_calls payload is returned to a different principal.
VulnCheck scores it 7.7 under CVSS 3.1 and 8.7 under CVSS 4.0. Affected versions are those before 1.101.0-rc.1.
GHSA-g5ff-637f-6q2m: file read through a credentials alias
Published on 1 October 2026 with no CVE, this High advisory (CVSS 8.1, scorer not stated) affects litellm before 1.95.0 and is fixed in 1.95.0. A low-privilege internal_user_viewer can read arbitrary local files. The request-body blocklist rejected vertex_credentials but missed the alias vertex_ai_credentials, so a crafted request to /utils/transform_request reaches the credential loader. The advisory says this can disclose environment variables and API keys, and that no reliable workaround exists. The reporter is rekter0.
What defenders should do
- Upgrade first. Move each proxy to the patched release for its branch from the table. Anything older than 1.95.0 is exposed to the file-read flaw as well, and anything before 1.101.0-rc.1 to the cache flaw.
- Treat internal users as a risk boundary. Both GitHub advisories need only a low-privilege account. Review who holds internal user and viewer roles, and prune accounts that are not needed.
- Hunt for admin use. For the salt-key bug, look for administrative actions or new admin sessions from accounts that were never admins. The advisory does not describe detection signals, so this is our suggestion, not vendor guidance.
- Rotate secrets if a proxy was reachable by untrusted internal users on an affected version. The proxy stores provider keys, and the file-read flaw can disclose environment variables.
- Harden JWT login. Ox Security advises requiring verified email claims at the identity provider, using stable subject identifiers, and not pre-provisioning privileged accounts by email alone.
- Be careful with the workaround. Setting
EXPERIMENTAL_UI_LOGIN=falsecloses the salt-key path but disables CLI SSO and Claude Code gateway login.
None of the sources we read reports exploitation in the wild for the salt-key flaw. The only exploitation data point is CISA's SSVC note of a proof of concept for CVE-2026-93355 and no known exploitation for CVE-2026-89032.