LiteLLM Proxy EUVD-2026-28502

Valid LiteLLM proxy API key for authentication (CVSS PR:L). The vulnerable POST /prompts/test endpoint must be network-accessible to the attacker (CVSS AV:N). The LiteLLM proxy must be running affected versions 1.80.5 through 1.83.6. No other special configuration or non-default settings are required-this endpoint is part of standard proxy deployment and does not need to be explicitly enabled. No user interaction required (CVSS UI:N). The authentication requirement is the primary limiting factor: attackers need credentials that may be distributed to multiple users in multi-tenant deployments, developers in testing environments, or third-party integrations. Organizations with tight API key controls and single-user proxy deployments face lower real-world risk than those with broadly distributed keys. Attack complexity is low (CVSS AC:L) once authentication is obtained-standard SSTI techniques apply without requiring deep application knowledge or timing attacks.

Real-world risk is high but not critical due to authentication requirement limiting attack surface. CVSS 8.6 reflects High severity with network attack vector (AV:N), low complexity (AC:L), and low privilege requirement (PR:L). The vector shows high confidentiality and integrity impact (VC:H/VI:H) with no availability impact (VA:N) and no scope change (SC:N/SI:N/SA:N), meaning attackers gain control within the proxy process but don't inherently pivot to other systems. EPSS data not provided, but GitHub security advisory publication significantly increases exploit probability as researchers and attackers now have detailed vulnerability information. Not currently in CISA KEV, indicating no confirmed mass exploitation campaigns, but the SSTI and RCE tags plus public advisory suggest proof-of-concept development is straightforward for attackers with template injection knowledge. Authentication requirement (PR:L) is the primary limiting factor-attackers need valid API keys, which may be broadly distributed in multi-user proxy deployments but restricts opportunistic scanning. Real priority depends on deployment model: high-risk for multi-tenant proxies with many key holders, moderate-risk for internal-only deployments with tight key management. The combination of simple exploitation (SSTI is well-understood), high impact (credential theft, command execution), and public disclosure makes this a genuine priority despite auth requirement. Patch availability in version 1.83.7 and workaround option (blocking endpoint at reverse proxy) provide clear remediation path.

An authenticated attacker with a valid LiteLLM proxy API key crafts a malicious prompt template containing server-side template injection payloads (e.g., Jinja2 syntax accessing Python object internals like {{''.__class__.__mro__[1].__subclasses__()}}). They submit this payload to POST /prompts/test, which the proxy renders without sandboxing. The template engine evaluates the malicious code, allowing the attacker to execute arbitrary Python code within the proxy process. The attacker reads environment variables to exfiltrate API keys for OpenAI, Anthropic, or other LLM providers configured in the proxy, along with database credentials. They establish persistence by modifying proxy configuration or installing a reverse shell. Public GitHub advisory provides detailed vulnerability information that simplifies proof-of-concept development for attackers familiar with SSTI techniques.