LiteLLM EUVD-2026-42350

Exploitation requires a user account holding high-privilege guardrail management rights within the LiteLLM deployment - specifically, the ability to call the production guardrail create or update API paths. The CVSS PR:H metric confirms that standard authenticated users cannot exploit this; only accounts with explicit guardrail administration access are in scope. The Custom Code Guardrails feature must be accessible on the deployment (AT:P in CVSS 4.0 reflects this specific precondition). Network access to the LiteLLM proxy API is required (AV:N). Exploitation is NOT possible by unauthenticated external actors, standard non-admin users, or read-only privileged accounts. The vulnerability does not affect deployments where guardrail management access is restricted to a single trusted owner who already has full system access, as that actor presents no incremental threat beyond their existing capabilities.

The CVSS 4.0 score of 2.1 accurately reflects the constrained real-world risk profile: PR:H mandates a highly privileged account specifically scoped to guardrail management, and AT:P signals a required attack precondition beyond standard network access. This is fundamentally an insider threat or post-compromise lateral movement scenario, not an opportunistic external attack. Despite the RCE and Code Injection tags, the impact metrics are low across all dimensions (VC:L/VI:L/VA:L), and there is no scope change to subsequent systems (SC:N/SI:N/SA:N), meaning the blast radius is confined to the proxy process. No EPSS data was provided in the input, no CISA KEV listing exists, and no public proof-of-concept has been identified - all consistent with a narrow attack surface. The primary operational risk is in multi-operator LiteLLM deployments where guardrail create/update rights are delegated to non-owner privileged users who might be malicious or whose accounts could be compromised. For single-operator self-hosted deployments where only the owner has admin access, the incremental risk of this vulnerability is minimal since the owner already has full system access.

A privileged LiteLLM operator with guardrail management rights - or an attacker who has compromised such an account - submits a malicious custom Python guardrail payload via the production create API endpoint. Because the production path lacks the sandboxing enforced by the test endpoint, the Python code executes directly inside the proxy process, reading environment variables such as OPENAI_API_KEY, ANTHROPIC_API_KEY, or database credentials, and exfiltrating them to an attacker-controlled endpoint. No public proof-of-concept has been identified, but the exploit is mechanically straightforward for any actor possessing valid guardrail admin credentials.