LiteLLM CVE-2025-11203

Exploitation targets the LiteLLM health endpoint's handling of the API_KEY parameter and requires the attacker to already hold valid authentication to the LiteLLM instance (PR:L). It additionally requires user interaction (UI:R), meaning a victim must trigger or be induced to trigger the vulnerable request flow rather than it being fully attacker-driven. These two limiting factors - needing a valid account plus interaction - significantly constrain realistic exploitation and keep impact bounded to disclosure of stored credentials (low confidentiality impact, no integrity or availability effect).

This is a genuinely low-priority issue despite being a credential-disclosure flaw. The CVSS 3.0 base score is only 3.5, and the vector (CVSS:3.0/AV:N/AC:L/PR:L/UI:R/S:U/C:L/I:N/A:N) tells a consistent story: although exploitation is over the network (AV:N) with low complexity (AC:L), it requires existing authentication (PR:L) AND user interaction (UI:R), with only low confidentiality impact and no integrity or availability impact. The description's statement that 'Authentication is required' aligns cleanly with PR:L - there is no conflict between the vector and the prose here. No EPSS score was provided, so real-world exploitation probability cannot be quantified from the input. The vulnerability is NOT in CISA KEV and no public exploit code is referenced, so there is no evidence of active exploitation or weaponization. The combined requirement of valid credentials plus user interaction substantially limits practical attack surface, making this a low real-world risk rather than a high-urgency item - the main caveat is that disclosed credentials (API keys) could enable downstream compromise, so impact may be understated by the base score if the leaked keys are high-value.

An authenticated but low-privileged LiteLLM user interacts with (or is lured into triggering) the health endpoint with a crafted API_KEY parameter, causing the service to return stored credentials in its response. The attacker harvests these leaked API keys and reuses them to access backend LLM providers or other integrated services, enabling further compromise. No public proof-of-concept is referenced, and exploitation is gated by both authentication (PR:L) and required user interaction (UI:R).