LiteLLM CVE-2026-114612

Requires an authenticated account with internal_user privileges on the LiteLLM proxy (CVSS PR:L); it is not remote-unauthenticated. For versions after 1.91.0 the flaw is exploitable in the DEFAULT configuration with no extra settings. For versions 1.87.0 through 1.90.x it is exploitable ONLY if EXPERIMENTAL_UI_LOGIN=true was explicitly set. The core condition is that the proxy reuses a single cryptographic context (salt key) for both at-rest secret sealing and session-token minting, so the API-key metadata flow can be abused to encrypt and return an attacker-chosen forged admin credential that is then accepted as a bearer token; host RCE specifically goes through the MCP stdio endpoint. Limiting factors: attacker must already hold a valid internal_user credential, and on 1.87.0-1.90.x the non-default EXPERIMENTAL_UI_LOGIN flag must be enabled. The only complete fix per the vendor is upgrading; the stopgap EXPERIMENTAL_UI_LOGIN=false closes the path but breaks CLI SSO and Claude Code gateway login.

This is a genuine act_now priority, and the signals are internally consistent rather than conflicting. The CVSS 3.1 vector (AV:N/AC:L/PR:L/UI:N/S:C, C:H/I:H/A:H, score 9.9) describes a network-reachable, low-complexity privilege escalation that only requires low privilege (an existing authenticated internal_user account) and crosses an authorization scope boundary (S:C) to reach proxy_admin and host-level remote code execution. The vendor GHSA advisory (GHSA-7hp6-4w63-5g45) confirms the mechanism - a single salt/encryption key is reused both to seal secrets at rest and to mint session/bearer tokens, so a user can have the API-key flow encrypt attacker-chosen metadata (a forged admin credential) and then replay that ciphertext as a bearer token (CWE-269/CWE-345/CWE-441). No EPSS score and no KEV status were supplied in the input, so exploitation-probability and active-exploitation signals are UNKNOWN here - the elevated urgency rests on the act_now decision label, the critical CVSS, the confirmed vendor advisory, and the fact that versions after 1.91.0 are exploitable in the DEFAULT configuration, not on any observed exploitation. The only material caveat is authentication: this is not an unauthenticated internet-wide bug - the attacker must already hold internal_user access to the proxy - which bounds it to insider or post-compromise scenarios while still warranting immediate patching given the RCE outcome.

An authenticated internal_user of a LiteLLM proxy (version after 1.91.0, default config) requests a new API key whose metadata carries a forged administrator credential as the 'secret' value; the proxy encrypts and returns that payload. The attacker replays the returned ciphertext as a bearer token, the proxy decrypts it with the same salt key and trusts the forged proxy_admin identity, then uses the MCP stdio endpoint to execute arbitrary commands on the host. No public exploit code is identified in the provided input, and given AV:N/AC:L the attack is low-complexity for anyone already holding an internal account.