LiteLLM Proxy CVE-2026-59823

Requires an authenticated caller holding a valid LiteLLM virtual key (PR:L) against a LiteLLM Proxy earlier than 1.83.9. The specific bypass is placing api_base (or base_url) inside the user_config request-body object instead of at the top level, because pre-1.83.9 is_request_body_safe only inspected and banned those keys at the top level and never examined user_config. No user interaction or non-default configuration toggle is needed beyond the proxy accepting user_config, which drives outbound router construction. Limiting factors: the attacker must already possess a working virtual key, and impact is confined to redirecting/exposing reachable internal or external endpoints (blind SSRF, low confidentiality) rather than full data theft or code execution.

This is a genuine but modest-severity SSRF (CWE-918). The vendor CVSS 4.0 vector (5.3, AV:N/AC:L/AT:N/PR:L/UI:N/VC:L/VI:N/VA:N/SC:L) is internally consistent with the description: network-reachable, low complexity, but requiring a valid virtual key (PR:L) and yielding only low confidentiality impact with a scope change to a subsequent system (SC:L). No EPSS score, no CISA KEV listing, and no public exploit code were provided, so exploitation status is 'no public exploit identified at time of analysis.' The signals do not conflict - a mid-band CVSS with no exploitation evidence points to a real-but-not-urgent fix-in-cycle issue rather than an emergency. The main real-world risk driver is not raw CVSS but deployment context: any LiteLLM Proxy that issues API keys to semi-trusted tenants exposes its internal network topology to those tenants. Note the impact is confidentiality-oriented and largely blind (endpoint exposure/redirection), not confirmed data exfiltration of internal responses, which is why VI/VA are N.

A tenant holding a valid but low-privilege LiteLLM virtual key crafts a proxy request that embeds api_base inside the user_config object rather than at the top level, evading the is_request_body_safe filter. The proxy then builds its outbound router from user_config and issues a server-side request to an attacker-chosen internal host (e.g., a cloud metadata endpoint or an internal admin service), letting the caller reach endpoints their key should not access. No public exploit code was provided, but the fix commit and PR diff make the bypass mechanics clear.