LiteLLM EUVD-2026-38138

Exploitation requires that the attacker already holds a low-privilege account or valid-at-some-point session token within the target LiteLLM proxy deployment (PR:L per CVSS 4.0 vector). The vulnerable code path is specifically triggered through the PROXY_ADMIN database API Key Generator component - meaning the proxy must be deployed in a configuration where the admin API is accessible and API key generation is enabled (which is the standard proxy deployment model). The vulnerability does not require user interaction and is remotely accessible over the network (AV:N, UI:N). What limits exploitation: the attacker must have prior authenticated access at some privilege level; purely external unauthenticated attackers cannot trigger this flaw. Additionally, the impact is bounded to the proxy tier - downstream LLM provider credentials or systems are only at risk if exposed through the proxy's session context.

The CVSS 4.0 base vector (AV:N/AC:L/AT:N/PR:L/UI:N/VC:L/VI:L/VA:L) places this at 2.1 - the lowest tier, reflecting that while network-exploitable without user interaction, it requires at minimum low-privilege access (PR:L) and delivers only limited confidentiality, integrity, and availability impact. The E:P modifier in the supplemental vector confirms a publicly available proof-of-concept (GitHub gist), which elevates real-world risk slightly above the base score alone would suggest. Critically, this vulnerability is NOT listed in the CISA KEV catalog, meaning confirmed active exploitation at scale has not been observed. The 'Information Disclosure' tag and session expiration root cause suggest the primary concern is credential persistence - an attacker who already has some foothold can extend or reuse their access rather than gaining initial compromise. This is a meaningful risk in multi-tenant LiteLLM deployments (e.g., enterprise proxies where different teams share one instance), but a low priority for single-user or tightly controlled environments. CVSS signals and description are consistent - no conflicting data identified.

An attacker with low-level access to a shared LiteLLM proxy deployment - such as a standard API user - obtains their own session token or intercepts a token that should have expired after logout or rotation. Leveraging the public proof-of-concept (https://gist.github.com/YLChen-007/39ed709ce322431658a05b951e91f278), the attacker manipulates the authenticate_user flow to present the expired token as valid, gaining continued authenticated access to the proxy API. This could allow the attacker to read model routing configurations, access request/response logs containing sensitive prompts, or generate additional API keys under the persistent session.