CVE-2026-114612: 
Chainguard vulnerability analysis and mitigation

CVE-2026-114612 is a critical privilege escalation vulnerability in LiteLLM (BerriAI's AI Gateway/proxy server) titled "Privilege Escalation to Proxy Admin via Cross-Domain Reuse of the Salt Key." The proxy reuses a single AES-256-GCM cryptographic context (the salt key) for both at-rest secret encryption and session token minting, allowing an authenticated internal_user to forge a proxy_admin credential and replay it as a bearer token. Affected versions span 1.87.0 through 1.100.3, 1.101.0–1.101.2, 1.102.0–1.102.1, 1.103.0, and 1.104.0-rc.1; versions after 1.91.0 are exploitable in the default configuration. It carries a CVSS v3.1 base score of 9.9 (Critical) (GitHub Advisory, Feedly).

The root cause is improper privilege management (CWE-269), insufficient verification of data authenticity (CWE-345), and a confused deputy pattern (CWE-441). LiteLLM's encrypt_value_helper function used the same AES-256-GCM key (derived from LITELLM_SALT_KEY) with no additional authenticated data (AAD) for both encrypting secrets stored in key metadata and for minting UI/CLI session tokens. An attacker with internal_user access calls the API key generation endpoint (/key/generate) with a crafted metadata.logging[].callback_vars field containing a JSON payload that mimics a proxy_admin session token (e.g., {"user_role": "proxy_admin", ...}). The proxy encrypts this payload and returns it; the attacker then strips the litellm_enc:: prefix and presents the raw ciphertext as a bearer token — the proxy decrypts it using the same key, trusts the embedded proxy_admin role, and grants full administrative access including arbitrary command execution via the MCP stdio endpoint (GitHub Advisory, Fix Commit).

Successful exploitation allows an authenticated internal user to fully escalate to proxy_admin, gaining complete control over the LiteLLM proxy. This includes the ability to execute arbitrary commands on the host via the MCP stdio endpoint, access all configured LLM API keys and secrets stored at rest, modify proxy configuration, and potentially pivot to downstream systems or LLM provider accounts. The scope change (CVSS S:C) reflects that the impact extends beyond the proxy itself to the underlying host and any connected LLM infrastructure (GitHub Advisory, Feedly).

As of the time of publication, no public proof-of-concept exploit code has been observed, and there is no confirmed evidence of in-the-wild exploitation (Feedly). The EPSS score is reported as 0.0, and the vulnerability does not appear in the CISA KEV catalog. However, the attack requires only low privileges (an internal_user account) and no user interaction, making it straightforward to exploit once an attacker has any authenticated foothold. Versions after 1.91.0 are exploitable in the default configuration without any special setup, significantly broadening the attack surface. Discovery credit goes to Hoa X. Nguyen of OPSWAT Unit 515 (GitHub Advisory).

1. Obtain internal_user credentials: Acquire or register an account with internal_user privileges on the target LiteLLM proxy (versions ≥ 1.91.0 in default configuration, or ≥ 1.87.0 with EXPERIMENTAL_UI_LOGIN=true).
2. Craft a forged admin payload: Construct a JSON string mimicking a proxy admin session token, e.g.:

{"token": "ui-token-attacker", "user_id": "attacker", "user_role": "proxy_admin", "team_id": "litellm-dashboard", "expires": "2099-01-01T00:00:00"}

3. Trigger encryption via the API key endpoint: Call POST /key/generate with the forged payload embedded in the metadata.logging[].callback_vars field (e.g., as langfuse_secret_key). The proxy encrypts this value using the shared salt key and returns it in the response.
4. Extract the ciphertext: Retrieve the encrypted value from the /key/info response; it will be prefixed with litellm_enc::. Strip this prefix to obtain the raw base64url-encoded ciphertext.
5. Replay as a bearer token: Present the extracted ciphertext as an HTTP Authorization: Bearer <ciphertext> header to any admin endpoint (e.g., /user/list, /key/list).
6. Achieve proxy_admin access: The proxy decrypts the token using the same salt key, trusts the embedded proxy_admin role, and grants full administrative access.
7. Execute arbitrary commands: Use the MCP stdio endpoint or other admin APIs to execute arbitrary commands on the host or exfiltrate all stored secrets (GitHub Advisory, Fix Commit).

• Network: Unexpected POST /key/generate requests from internal_user accounts with unusually large or JSON-structured metadata.logging[].callback_vars fields; subsequent requests to admin-only endpoints (e.g., /user/list, /key/list, /model/info) using bearer tokens prefixed with litellm_login_ or raw base64url strings not matching the sk- pattern.
• Logs: LiteLLM proxy access logs showing an internal_user account successfully authenticating to proxy_admin-restricted endpoints; /key/info calls immediately following /key/generate from the same session; admin actions (user creation, key deletion, model changes) attributed to accounts that should not have admin rights.
• Process: Unexpected child processes spawned by the LiteLLM proxy process (e.g., shell commands, curl, wget, python) if the MCP stdio endpoint is abused for remote code execution.
• File System: New or modified configuration files, unexpected scripts, or cron jobs created under the LiteLLM service account after suspicious admin API activity (GitHub Advisory).

Upgrade LiteLLM to one of the patched versions: 1.100.4, 1.101.3, 1.102.2, 1.103.1, or 1.104.0-rc.2. The fix introduces separate AES-256-GCM cryptographic contexts for at-rest secrets and session tokens by binding the token prefix (litellm_login_) as authenticated additional data (AAD), preventing cross-domain ciphertext reuse (Fix Commit). If immediate upgrade is not possible, set EXPERIMENTAL_UI_LOGIN=false to disable the vulnerable authentication path (note: this breaks CLI SSO and Claude Code gateway login). Additionally, restrict internal_user account creation and monitor for anomalous admin API access patterns (GitHub Advisory).

The vulnerability was discovered by Hoa X. Nguyen of OPSWAT Unit 515 and disclosed via GitHub Security Advisories on September 30, 2026, with the CVE published on October 22, 2026. The BerriAI maintainer (yuneng-berri) promptly backported the fix across multiple stable branches (1.100.x, 1.101.x, 1.102.x, 1.103.x, and the 1.104.0 release candidate), indicating a responsive vendor posture (GitHub Advisory). No significant broader community or media commentary has been identified at this time.