# LiteLLM CVE-2026-114612: how one shared key turned an internal user into proxy admin

> LiteLLM CVE-2026-114612 lets an internal user forge a proxy admin token and run commands via MCP stdio. Affected versions, fixes, and what to check.

- Published: 2026-10-30
- Author: Enforster AI (https://enforster.ai)
- Category: AI Security
- Tags: AI Security, LLM, Access Control, MCP, Security Operations
- Canonical URL: https://blog.enforster.ai/litellm-cve-2026-114612-salt-key-privilege-escalation

## Key takeaways

- CVE-2026-114612 lets an authenticated LiteLLM internal_user escalate to proxy admin and, per the advisory, run arbitrary commands on the host through the MCP stdio endpoint.
- The root cause is key reuse: LiteLLM used the same encryption key to seal secrets at rest and to mint UI and CLI session tokens, so a stored ciphertext could be replayed as a bearer token.
- Fixed releases are LiteLLM 1.100.4, 1.101.3, 1.102.2, 1.103.1, and 1.104.0rc2; versions from 1.91.0 are exploitable in the default configuration.
- GitHub rates CVE-2026-114612 CVSS 3.1 9.9 (Critical); the CVE record was published on October 22, 2026.
- If you cannot upgrade, setting EXPERIMENTAL_UI_LOGIN=false disables the vulnerable path but also breaks CLI SSO and Claude Code gateway login.

---

CVE-2026-114612 is a critical privilege escalation in the LiteLLM proxy, the open-source gateway many teams put in front of their LLM providers. An authenticated user with the `internal_user` role can get the proxy to encrypt a forged admin credential, replay it as a bearer token, and become proxy admin. The advisory says that admin access then allows arbitrary commands on the host through the MCP stdio endpoint. Upgrade to 1.100.4, 1.101.3, 1.102.2, 1.103.1, or 1.104.0rc2, depending on your release line.

The bug is a clean example of a classic cryptographic mistake: one key, two jobs. This article reflects the GitHub advisory and CVE record as of October 30, 2026.

## What is CVE-2026-114612?

LiteLLM's GitHub advisory [GHSA-7hp6-4w63-5g45](https://github.com/BerriAI/litellm/security/advisories/GHSA-7hp6-4w63-5g45) describes it as privilege escalation to proxy admin through cross-domain reuse of the salt key. The [CVE record](https://www.cve.org/CVERecord?id=CVE-2026-114612), assigned by GitHub, was published on October 22, 2026 with a CVSS 3.1 score of 9.9 (`AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H`). It is classed as CWE-269 (improper privilege management), CWE-345 (insufficient verification of data authenticity), and CWE-441 (confused deputy).

The advisory credits Hoa X. Nguyen of OPSWAT Unit 515 with the discovery. It does not report exploitation in the wild, and neither do the other sources reviewed for this article. Check the CVE record and CISA's KEV catalog before you deprioritize it.

## Which LiteLLM versions are affected?

| Release line | Affected | Fixed in |
| --- | --- | --- |
| 1.91.0 to 1.100.x | `>= 1.91.0, < 1.100.4` | 1.100.4 |
| 1.101.x | `>= 1.101.0, < 1.101.3` | 1.101.3 |
| 1.102.x | `>= 1.102.0, < 1.102.2` | 1.102.2 |
| 1.103.x | `>= 1.103.0, < 1.103.1` | 1.103.1 |
| 1.104.0 pre-release | `>= 1.104.0rc1, < 1.104.0rc2` | 1.104.0rc2 |

Versions 1.87.0 through 1.90.x are affected only if `EXPERIMENTAL_UI_LOGIN=true` was set explicitly. From 1.91.0 onward, the advisory says the flaw is exploitable in the default configuration.

The precondition is an authenticated account with `internal_user` privileges. That is a low bar in many deployments: internal users are typically the developers and teams who were given access to the gateway so they could create their own keys.

## How does the attack work?

The advisory puts the root cause in one line: the proxy "uses one encryption key for two purposes: sealing secrets at rest and minting session tokens."

LiteLLM's [production guide](https://docs.litellm.ai/docs/proxy/prod) describes `LITELLM_SALT_KEY` as the key used for "encrypting and decrypting stored variables", such as your LLM provider credentials. The same key also protected the session tokens that the UI and CLI login flows hand out. Because both kinds of ciphertext were produced the same way, the proxy could not tell a sealed secret from a session token.

The advisory describes the attack in four steps:

1. An internal user requests a new API key and includes a crafted metadata field that holds a forged admin credential as its "secret" value.
2. The proxy encrypts that value with the shared key, as it would any stored secret, and returns it.
3. The user presents the returned ciphertext as a bearer token.
4. The proxy decrypts it, trusts the forged admin identity inside, and grants proxy admin access.

The proxy is the confused deputy here: it performed the privileged act of encryption on the attacker's behalf, then trusted its own output.

### Why does proxy admin mean code execution?

The advisory links the escalation to arbitrary commands through the MCP stdio endpoint. LiteLLM's [MCP documentation](https://docs.litellm.ai/docs/mcp) shows how a stdio MCP server is defined: a `command`, optional `args`, and optional `env`, which the proxy launches as a local process. Servers can be added through the UI or the `/v1/mcp/server` API, not only in `config.yaml`.

```yaml
mcp_servers:
  example_tool:
    transport: "stdio"
    command: "uvx"
    args: ["some-mcp-server"]
```

Anyone who can register a stdio server chooses what the proxy host executes. The current docs say stdio servers are disabled unless the proxy process starts with `LITELLM_ENABLE_MCP_STDIO=true`. The advisory does not say whether that switch blocks this attack on affected versions, so do not treat it as a mitigation on its own.

> **Admin access is the real prize:**
>
> Even without command execution, proxy admin is the most sensitive role on an LLM gateway. LiteLLM's docs describe the master key as the credential that "authenticates admin API calls and is the Admin UI login password." An attacker with that level of access can manage keys, users, models, and routing for every team behind the proxy.

## What did the fix change?

The fix gives session tokens their own cryptographic context. In the backport commit [1d5fdc8](https://github.com/BerriAI/litellm/commit/1d5fdc87fed66b49e1df8cf7d708ad93249eb7d0), titled "bind UI/CLI session tokens to their own AES-GCM context", LiteLLM:

- adds a token prefix, `litellm_login_`, to UI and CLI session tokens;
- binds that prefix into the AES-GCM authentication tag as associated data, so a ciphertext minted without it fails authentication when presented as a token;
- replaces the generic decryption call in the token check with a dedicated `decrypt_bearer_token` function that returns nothing if the prefix is missing or authentication fails;
- leaves the format of values already stored at rest unchanged, so existing encrypted credentials still decrypt.

The commit adds an end-to-end test confirming that encrypted stored values are rejected as bearer tokens. This is domain separation done with standard tools: the same key, but authenticated data that ties each ciphertext to its purpose.

## What should you do now?

### 1. Find every LiteLLM instance and its version

Check package installs and container images, including the ones run by teams outside your platform group.

```bash
pip show litellm | grep -i '^version'
docker ps --format '{{.Image}}' | grep -i litellm
```

Any version in the table above needs an upgrade. Upgrade within your release line to the fixed version, or move to a newer line.

### 2. If you cannot upgrade today, close the login path

The advisory's workaround is `EXPERIMENTAL_UI_LOGIN=false`. It disables the vulnerable authentication path but, in the advisory's words, "also breaks CLI SSO and Claude Code gateway login." Plan for that disruption and tell affected users before you flip it.

### 3. Review who holds the internal_user role

Every internal user on an affected version could have become admin. List them, remove accounts that no longer need gateway access, and treat this as a reminder that "low privilege" on a gateway is only as low as the gateway's own authorization checks.

### 4. Look for signs of abuse

The advisory publishes no indicators of compromise, so these checks are our suggestions, not vendor guidance:

- API keys created by internal users whose metadata contains unusual or credential-shaped values.
- Admin actions performed by identities that are not on your list of admins.
- MCP servers you did not register, especially any using the stdio transport.
- Unexpected child processes spawned by the proxy process on the host.

### 5. Decide on secret rotation

If you find evidence of abuse, assume the attacker could reach anything a proxy admin can, including the provider credentials the proxy manages, and rotate those credentials at the provider. Rotating `LITELLM_SALT_KEY` itself is not a simple swap: the production guide warns "Do not change it after adding a model", because stored credentials encrypted under the old key become unreadable. Follow LiteLLM's documented procedures rather than changing it in place.

> **Keep the gateway off the internet:**
>
> An LLM gateway's admin surface belongs on a private network or behind an identity-aware proxy. That does not stop an insider, which is exactly who this bug needs, but it removes everyone else from the threat model.

## What is the broader lesson for AI gateways?

Key separation is old advice, and [NIST SP 800-57 Part 1](https://csrc.nist.gov/pubs/sp/800/57/pt1/r5/final) is the standard reference for key-management practice. The LiteLLM bug shows why the advice matters: once a system will encrypt attacker-chosen data with the same key it uses to authenticate users, the attacker can mint their own credentials.

Two design checks are worth applying to any gateway you run or buy:

- **Does anything the gateway encrypts on a user's behalf share a key or context with its tokens?** If so, ask how the two are kept apart. Authenticated associated data, separate derived keys, or signed tokens with a distinct key are all reasonable answers.
- **What can an admin execute?** Gateways increasingly host MCP servers and tool integrations. A stdio MCP server is a command the host will run, so the admin role on a gateway is often equivalent to shell access on its host. Scope and monitor it accordingly.

CVE-2026-114612 is unrelated to the [LiteLLM 1.107.0 supply chain compromise](https://blog.enforster.ai/litellm-1-107-0-supply-chain-compromise), which needs a different response; check both if you run LiteLLM. If you are deciding whether to run a gateway yourself or use a hosted one, our guide to [vetting AI aggregators and model gateways](https://blog.enforster.ai/ai-aggregator-data-exposure-vetting-model-gateways) covers what to ask. For the risks of the MCP servers a gateway can launch, see [vetting third-party MCP servers](https://blog.enforster.ai/vetting-third-party-mcp-servers).