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

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 describes it as privilege escalation to proxy admin through cross-domain reuse of the salt key. The CVE record, 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?

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 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 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.

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.

What did the fix change?

The fix gives session tokens their own cryptographic context. In the backport commit 1d5fdc8, 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.

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.

What is the broader lesson for AI gateways?

Key separation is old advice, and NIST SP 800-57 Part 1 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, 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 covers what to ask. For the risks of the MCP servers a gateway can launch, see vetting third-party MCP servers.