LiteLLM CVE-2026-114612: One Key Lets an Internal User Become Proxy Admin

LiteLLM, the open-source proxy many teams put in front of their LLM providers, has a privilege escalation flaw that turns any internal user into a proxy administrator. CVE-2026-114612 carries a CVSS 3.1 score of 9.9 (a secondary score from the GitHub CNA; NVD has no primary score yet), and the end of the chain is command execution on the host through the proxy’s MCP stdio endpoint. Fixes exist in four stable release lines and one release candidate (1.104.0-rc.2). The GitHub advisory also gives a CVSS 4.0 score of 7.7.

The cause is a design mistake, not a memory bug. Per the GitHub advisory, the proxy uses one encryption key for two jobs: sealing secrets at rest and minting session tokens.

How the attack works

The advisory describes the sequence in four steps:

1. An authenticated user with internal_user privileges asks the proxy for a new API key.
2. They put a crafted metadata field in that request, containing a forged administrator credential in the position where a secret would sit.
3. The proxy encrypts that payload and returns it.
4. The attacker presents the returned ciphertext as a bearer token. The proxy decrypts it, trusts the forged administrator identity and grants full admin access.

From there, the advisory says the attacker can run arbitrary commands on the host through the MCP stdio endpoint. That endpoint exists so the proxy can launch local MCP servers as subprocesses, which is exactly why administrator access to it is so much worse than administrator access to a dashboard.

The weakness classes NVD records are CWE-269 (improper privilege management), CWE-345 (insufficient verification of data authenticity) and CWE-441 (unintended proxy or intermediary). The first two fit the story: the proxy treated “this decrypts correctly” as proof that it had issued the token.

We have not reproduced the flaw. The mechanics above are the advisory’s account, and the fix commit we read is consistent with it: a backport commit titled “bind UI/CLI session tokens to their own AES-GCM context” changes encrypt_decrypt_utils.py and auth_checks.py. That is the same kind of separation the advisory’s root cause calls for. It is our reading of the commit message, not a statement from the maintainers.

Who is exposed

This is not an unauthenticated bug. The CVSS vector is AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H: network reachable, low complexity, low privileges, scope changed. The score is 9.9 because a low-privileged account gets everything.

Our assessment is that the practical exposure depends on who holds internal-user accounts. Deployments that issue keys to many developers, contractors or automated agents have a large pool of accounts that already meets the precondition. A single-tenant proxy used by two engineers is a different risk from a shared platform proxy.

On versions, the sources differ slightly in framing, so read both:

• The GitHub advisory lists vulnerable ranges from 1.91.0 up to each fixed release, with versions 1.87.0 through 1.90.x exploitable only when EXPERIMENTAL_UI_LOGIN=true is set. It says versions later than 1.91.0 are exploitable in the default configuration; it does not say whether 1.91.0 itself is.
• The NVD description says “From 1.87.0” until the fixed releases and repeats the same conditional for 1.87.0 through 1.90.x.

Fixed releases: 1.100.4, 1.101.3, 1.102.2, 1.103.1 and 1.104.0-rc.2 (the 1.104 line is fixed only in a release candidate). The GitHub releases page shows v1.100.4 and v1.104.0-rc.2 both published on 30 September 2026, so patched builds were available weeks before the CVE entry appeared on 22 October. NVD lists the 9.9 score as a secondary score from the GitHub CNA, and its analysis was still pending when we checked on 5 November. Credit in the advisory text goes to Hoa X. Nguyen of OPSWAT Unit 515.

Exploitation status

No evidence found as of 5 November 2026 in the CISA Known Exploited Vulnerabilities catalogue (feed version 2026.11.04), the GitHub advisory or NVD that CVE-2026-114612 is exploited. The FIRST EPSS API returned a score of 0.00319 for 4 November. That is a model estimate and says little about a targeted attacker with a valid internal account.

CISA’s SSVC record in NVD (30 October, CISA Coordinator) reads exploitation: none, automatable: no, technical impact: total.

Context matters here. LiteLLM has a history on this site: CVE-2026-42271, an MCP stdio command execution flaw, is in KEV (added 8 June 2026), and we covered a separate Host header bypass. KEV listing of a sibling bug tells us attackers look at this product. It does not tell us this CVE is being used.

What to do

1. Upgrade to the fixed release for your line: 1.100.4, 1.101.3, 1.102.2, 1.103.1 or 1.104.0rc2 or later. Check the version your container image actually runs, not the one in your manifest.
2. If you cannot upgrade today, set EXPERIMENTAL_UI_LOGIN=false. The advisory says this disables the vulnerable authentication path but also breaks CLI SSO and Claude Code gateway login, so warn users first.
3. Review who holds internal_user accounts and which keys they have minted. Remove stale or shared ones. The attack needs a valid account, so this directly shrinks exposure.
4. Restrict the MCP stdio endpoint. Our recommendation: if you do not run local stdio MCP servers through the proxy, block the MCP stdio test routes at the network layer (the advisory does not name the route, so confirm the path in your version) so a future admin-level bug cannot reach it.
5. Hunt for abuse. Look for newly created API keys with unusual metadata content, admin-level requests from accounts that should not have them, and unexpected child processes spawned by the proxy. We have not tested these queries against a live deployment, so tune them before relying on them.
6. Rotate secrets the proxy holds (provider API keys, database credentials) if you find evidence of abuse, since host command execution exposes everything the process can read.

The broader lesson is about key hygiene in AI gateways. These proxies hold provider keys for several vendors and increasingly launch tools as subprocesses. A shared encryption key across storage and authentication is the kind of shortcut that works until someone supplies their own plaintext. Separate keys, or separate cryptographic contexts, for each purpose is the fix the maintainers chose.

References

• GitHub Security Advisory — GHSA-7hp6-4w63-5g45: LiteLLM internal_user to proxy_admin escalation
• NVD — CVE-2026-114612
• GitHub — LiteLLM commit 1d5fdc8: bind UI/CLI session tokens to their own AES-GCM context
• GitHub — LiteLLM release v1.100.4
• FIRST — EPSS score for CVE-2026-114612
• CISA — Known Exploited Vulnerabilities Catalog