LiteLLM CVE-2026-114612: Salt Key Reuse Gives Proxy Admin and RCE

LiteLLM proxy versions from 1.91.0 have a high-severity privilege escalation, published as CVE-2026-114612 (GHSA-7hp6-4w63-5g45). An authenticated user with internal_user privileges can become proxy_admin and then run arbitrary commands on the proxy host through the MCP stdio endpoint. If you run a LiteLLM proxy for a team, upgrade to the patched release for your line. If you cannot, the stopgap breaks Claude Code gateway login.

The reason this matters for coding-agent users is where the proxy sits. A LiteLLM gateway typically holds the provider keys for a whole team and brokers the model calls that agents make. Admin on that service is a short step from every key behind it. The tool's page in the Beam CVE database is LiteLLM.

Quick answers

What the advisory says happened

According to the GitHub advisory, the proxy uses one encryption key, the salt key, for two different purposes: sealing secrets at rest and minting session tokens. That is the root cause. When one key does both jobs, a value the server encrypts on your behalf can later be accepted as a credential the server issued.

The advisory classes the weaknesses as CWE-269 (improper privilege management), CWE-345 (insufficient verification of data authenticity) and CWE-441 (confused deputy). The discovery credit goes to Hoa X. Nguyen of OPSWAT Unit 515. The advisory was published on September 30, 2026 in the BerriAI/litellm repository, reached the National Vulnerability Database on October 22 and was added to GitHub's advisory database on October 27.

The attack chain, step by step

The advisory describes the exploit in a few sentences. Spelled out:

1. The attacker holds an internal_user account. This is a normal, low-privilege role on the proxy.
2. They request a new API key and put a forged admin credential in the key's metadata field. The metadata contains the structure of an admin identity, placed where the proxy expects a "secret" value to be stored.
3. The proxy encrypts that payload with the salt key and returns it. The server has now produced a sealed blob whose plaintext is attacker-chosen.
4. The attacker presents the returned value as a bearer token. Because session tokens are decrypted with the same key, the proxy decrypts the blob and trusts the identity inside it.
5. The proxy treats the caller as proxy_admin. That grants full administrative access.
6. The attacker uses the MCP stdio endpoint to execute commands. An admin can register a stdio MCP server, which means the proxy launches a local process. That is remote code execution on the host.

Note what is missing: there is no memory corruption and no guessing. The server is tricked into signing, in effect, what the attacker wrote. This is the confused-deputy pattern the CWE-441 label describes.

Who is affected

Versions later than 1.91.0 are exploitable in the default configuration, per the advisory. Versions 1.87.0 through 1.90.x are exploitable only if EXPERIMENTAL_UI_LOGIN=true was explicitly set.

The advisory's affected and patched ranges are:

The practical exposure depends on who has accounts. A proxy that only one developer uses on localhost is a low risk. A shared gateway where many people hold internal_user keys is the case to fix first, since any one of them (or anyone who steals one of their keys) can attempt the chain. The CVSS v4 vector is network, low complexity, low privileges required, no user interaction, with high impact on confidentiality, integrity and availability of the vulnerable system. GitHub lists an EPSS score of about 0.3 percent at the time of writing; we found no report of exploitation in the wild.

Why one key for two jobs is the real bug

Cryptographic keys should have a single purpose. Sealing a secret at rest is a confidentiality job: the server wants to store something so that only it can read it later. Minting a session token is an authenticity job: the server wants to hand out something that only it could have produced, so it can trust it on the way back. When both jobs share a key, the two guarantees blur. Anything the server will seal for a user, including text the user chose, becomes something the server will later accept as proof of who that user is.

That is why the exploit needs no cryptanalysis. The attacker never learns the key. They only need an endpoint that encrypts attacker-controlled text and returns the result, and the API-key metadata field was exactly that. The general defence is domain separation: derive a distinct key for each purpose, or include a purpose label inside the authenticated data, and reject tokens whose label does not match. It is also why the advisory's wording about "cross-domain reuse" is a fair title for the class of bug.

For operators, the broader lesson is to treat any feature that echoes user-supplied data back in sealed form as sensitive, and to keep admin-capable features such as stdio MCP registration behind a separate, explicit permission rather than the role label alone. Restricting who can register command-launching MCP servers limits the blast radius even if a future bug lets someone claim a higher role.

What this means if you run AI coding agents

If your team runs a LiteLLM proxy in front of Claude Code, Codex-style tools or custom agents, work through this list.

1. Check the version. On the proxy host or in the container, run pip show litellm and read the Version line. For container images, check the image tag and digest, not only the tag name.
2. Upgrade to the fixed release for your line. Pin it, for example pip install "litellm==1.100.4" if you are on the 1.100 line, and rebuild images instead of patching in place. The advisory links the release notes for each version: 1.100.4, 1.101.3, 1.102.2, 1.103.1 and 1.104.0-rc.2.
3. If you cannot upgrade today, set EXPERIMENTAL_UI_LOGIN=false. This disables the vulnerable authentication path. The advisory is explicit about the cost: it breaks CLI SSO and Claude Code gateway login. Plan for developers to lose that sign-in route until you upgrade.
4. Reduce who holds internal_user keys. The attack needs one. Remove accounts you no longer need and rotate keys that sit in shared places.
5. Review the MCP configuration on the proxy. Look for stdio MCP servers you did not register. A stdio entry is a command the host will run.
6. Look for signs of abuse. The advisory gives no indicators, so these are our suggestions: API keys created with unusually large or structured metadata values, proxy_admin actions from accounts that should not have that role, and new processes spawned by the proxy.
7. Treat provider keys as exposed if you find anything. Rotate the upstream keys the proxy holds, then the proxy's own master and salt keys. Our runbook for the first 24 hours after a vendor breach covers the rotation order.

A related note on separate keys: the fix direction implied by the advisory is that one key should not serve two purposes. If you operate your own gateway or token service, derive distinct keys per purpose and bind each token to its purpose, so a ciphertext produced for one job cannot be replayed for another.

How this fits earlier LiteLLM and gateway news

This is not the first time LiteLLM has appeared in our coverage this month. The LiteLLM 1.107.0 PyPI and Docker compromise was a supply-chain incident aimed at AI credentials, a different mechanism from this authorization bug, but with the same prize: the keys a proxy holds. The pattern repeats across the ecosystem. The MCP TypeScript SDK advisories and the Langflow MCP stdio RCE show that features which launch local processes from configuration are a recurring route to code execution when access control around them is weak. The vLLM advisories show the same trust problem on the serving side.

For the exposure angle, the Symantec report on agents abusing exposed AI endpoints explains why a gateway full of provider keys is attractive to attackers.

What Beam can and cannot do here

Beam does not apply to the server-side bug. It runs on a developer machine, watching what Claude Code, Codex and similar agents do, flagging risky actions such as credential exposure and destructive commands, and scanning skill and MCP configurations with a set of heuristics and a version-pin check. It does not inspect, patch or monitor a LiteLLM proxy.

There are two modest client-side overlaps. First, if an agent session prints or writes the gateway key it uses, Beam's credential detection can flag that locally, and its redaction runs before anything is stored. Second, beam scan --mcp checks an MCP configuration for risky patterns and unpinned dependency references, which is a review aid for the client-side configs you do control. It does not launch or inspect servers, and it says nothing about the stdio primitive on the proxy. Both are heuristic and on-device, and neither is a substitute for upgrading the proxy. See how Beam keeps data local and how it works.

Frequently asked questions

Which LiteLLM versions are affected by CVE-2026-114612?

The advisory lists litellm from 1.91.0 up to the patched releases 1.100.4, 1.101.3, 1.102.2, 1.103.1 and 1.104.0rc2, depending on your release line. Versions 1.87.0 through 1.90.x are exploitable only if EXPERIMENTAL_UI_LOGIN=true was set explicitly.

How severe is CVE-2026-114612?

GitHub rates it high, with a CVSS v4 score of 7.7. The attack is network-reachable and low complexity, needs low privileges (an internal_user account) and no user interaction, and has high confidentiality, integrity and availability impact on the proxy.

Is there a workaround if I cannot upgrade?

Yes. The advisory says to set EXPERIMENTAL_UI_LOGIN=false, which disables the vulnerable authentication path. It also breaks CLI SSO and Claude Code gateway login, so it is a stopgap, not a fix.

How do I know if someone exploited this against my proxy?

The advisory does not describe indicators. Reasonable checks, which are our suggestions, are to review keys created by internal users with unusual metadata values, unexpected proxy_admin activity, and any MCP stdio server entries you did not add.

Why does a LiteLLM bug matter for people running coding agents?

The proxy often holds every provider key a team uses and fronts the model calls of coding agents. Admin on that host means access to those keys and command execution next to them. Rotate keys if you suspect exposure.

Can Beam detect or block this?

No. Beam watches agent actions and scans skills and MCP configs on your own machine. It does not inspect or protect a LiteLLM server. It can only help on the client side, for example by flagging credentials that an agent session exposes.

Related reading

• LiteLLM 1.107.0 PyPI and Docker compromise
• MCP TypeScript SDK advisories
• MCP security in practice
• Langflow MCP stdio RCE
• LiteLLM file read via vertex_ai_credentials and SSO debug XSS
• Source: GitHub advisory GHSA-7hp6-4w63-5g45 and the NVD record

Versions and advisory details are accurate as of October 27, 2026. Check the linked advisory and LiteLLM's release notes for changes.