LiteLLM Proxy Cryptographic Reuse Enables Admin Takeover via Forged Tokens

An authenticated internal user can seize administrative control of the LiteLLM proxy by exploiting a cryptographic weakness in versions ranging from 1.87.0 to 1.104.0-rc.2. By crafting metadata that includes a forged administrator credential, the attacker tricks the API-key flow into encrypting and returning this malicious data. Replaying that specific ciphertext as a bearer token forces the proxy to accept the forged identity, granting full administrative access and the ability to run arbitrary commands through the Model Context Protocol standard input/output endpoint.

How it unfolded

• The attacker begins as an authenticated internal user with access to the proxy’s API-key flow.
• They submit crafted metadata containing a forged administrator credential for encryption.
• The proxy returns the encrypted token, which the attacker replays as a bearer token.
• The system trusts the forged identity, enabling administrative access and command execution.

Who is affected

LiteLLM proxy versions from 1.87.0 through 1.90.x are vulnerable only if the EXPERIMENTAL_UI_LOGIN feature is explicitly enabled. However, versions released after 1.91.0 are exploitable in their default configuration, significantly broadening the attack surface for managed service providers using these setups. This affects multiple release lines, including versions up to 1.100.4, 1.101.3, 1.102.2, 1.103.1, and the release candidate 1.104.0-rc.2.

The fix

BerriAI has released patches for all affected version lines. The vulnerability is resolved in LiteLLM 1.100.4, 1.101.3, 1.102.2, 1.103.1, and 1.104.0-rc.2. Administrators should update their proxy servers to these specific versions immediately to eliminate the risk of unauthorized administrative access and command execution via the MCP endpoint.

What made it possible

This incident highlights the dangers of cryptographic context reuse, where a single key or context handles both static secrets and dynamic session tokens. Teams usually isolate these functions to prevent cross-contamination. When an attacker can influence the input to a cryptographic operation, they may craft data that, when encrypted and replayed, masquerades as a privileged token. This technique serves the privilege escalation stage of an intrusion, turning a low-level authenticated session into a high-privilege administrative foothold without needing external exploitation vectors.

What to do and how to stay safe: LiteLLM

• Audit your LiteLLM proxy version and update to the patched releases listed above.
• Review logs for any unusual bearer token usage or unexpected administrative actions.
• Ensure that experimental features are disabled unless strictly necessary for your workflow.
• Monitor the MCP stdio endpoint for unauthorized command execution attempts.

Step-by-step guide: What Is Virtual Patching: How It Works Without Code Changes

General security guidance from the RedTeam Tribune newsroom. It is not confirmed advice from the organisations named in this story.

Frequently asked questions

What is the CVSS score for CVE-2026-114612?

The National Vulnerability Database rates this vulnerability as critical with a CVSS score of 9.9.

Which LiteLLM versions are affected by this flaw?

Versions from 1.87.0 through 1.104.0-rc.2 are affected, excluding the specific patched versions released by BerriAI.

Does this vulnerability require external access to exploit?

No, the attacker must be an authenticated internal user to craft and replay the forged metadata.