· via dev.to (home feed)
Critical LiteLLM proxy flaw lets low-privilege users escalate to admin and RCE
A CVSS 9.9 vulnerability in LiteLLM's proxy lets any authenticated low-privilege user forge an admin session token and reach remote code execution. Patched releases are out for every affected branch.

Critical LiteLLM proxy vulnerability
A vulnerability tracked as CVE-2026-114612 and rated 9.9 out of 10 on the CVSS v3.1 scale allows any authenticated low-privilege account on a LiteLLM proxy server to seize full administrator control and, in a follow-on step, execute commands on the host. According to a vulnerability report published on dev.to, every release from 1.87.0 through 1.104.0-rc.1 is affected, along with Chainguard's LiteLLM container images.
LiteLLM, the BerriAI-maintained open-source proxy that fronts large-language-model APIs in many AI stacks, is therefore exposed wherever an untrusted user holds even a basic internal account.
How the token confusion works
The report traces the bug to a single AES-256-GCM encryption context and key-derivation path being shared by two unrelated features: encrypting secrets stored at rest in metadata fields, and minting ephemeral session tokens that authenticate the web UI and CLI. Neither purpose was bound into the ciphertext as Associated Authenticated Data, so the proxy cannot distinguish an encrypted metadata blob from an encrypted administrator session — both are sealed with the same key and the same construction.
That symmetry turns an ordinary API call into an encryption oracle. An attacker with internal-user credentials asks the proxy to generate an API key while hiding hand-crafted JSON that mimics an admin session inside a user-writable encrypted field, with the Langfuse secret key slot cited as one example. The proxy encrypts the payload and hands back the ciphertext. The attacker then replays that string as an HTTP Bearer token, which the proxy accepts as a valid administrator login. From there, the report says, remote command execution is reachable through the Model Context Protocol's stdio transport.
The issue is filed under CWE-269, CWE-345 and CWE-441. Exploitation is demonstrably practical: the project's own end-to-end regression test performs the whole chain, from the key-generation endpoint to replay against the user-listing endpoint. At the time of the report, EPSS stood at 0.24 percent and the flaw was not yet listed in CISA's Known Exploited Vulnerabilities catalog.
Fixes available on every branch
Patch commit 1d5fdc8 gives session tokens a dedicated sealed format: they are now encrypted with the token purpose encoded as AAD and prefixed with litellm_login_, and decryption rejects anything lacking the prefix, so a ciphertext minted for metadata storage can no longer be replayed as a login. The fix was backported to every maintenance branch, producing patched releases 1.100.4, 1.101.3, 1.102.2, 1.103.1 and 1.104.0-rc.2. The report also points to GitHub Security Advisory GHSA-7hp6-4w63-5g45 and the NVD record for the CVE.
Hardening and cleanup steps
For teams unable to upgrade immediately, the report recommends interim measures: WAF or reverse-proxy rules that reject Authorization headers containing v2:gcm: or litellm_enc:: prefixes, disabling the MCP stdio transport in production so admin access cannot become host command execution, and turning off the experimental UI login on legacy 1.87.0 through 1.90.x deployments.
After patching, operators are advised to inventory every LiteLLM proxy and container image across environments, audit the LiteLLM_VerificationToken table for API keys carrying unexpected JSON inside metadata.logging[].callback_vars (a sign someone staged the attack), and rotate both the proxy MASTER_KEY and LITELLM_SALT_KEY wherever untrusted users had internal access on an unpatched instance.
Why it matters
This is not an exotic zero-day requiring a novel exploit primitive — it is a low-privilege account turning one HTTP header into full control of a gateway that holds every model-provider credential an organisation uses. The underlying mistake, reusing one key and cipher across two purposes without any context binding, is a classic domain-separation failure that other self-hosted infrastructure projects could equally carry, making this worth studying beyond the LiteLLM ecosystem. And because the proof of concept ships as an official regression test, the effort required to replicate it is minimal despite the currently low EPSS score. Patching promptly is cheap; the alternative is rotating every secret the gateway has ever touched.
- #security
- #litellm
- #ai-gateway
- #vulnerability
- #encryption