LiteLLM EUVD-2026-38156

Exploitation requires a valid low-privileged authenticated account on the LiteLLM enterprise API, consistent with the PR:L metric in the provided CVSS 4.0 vector. The enterprise banned keywords hook (enterprise/enterprise_hooks/banned_keywords.py) must be actively deployed and configured with at least one banned keyword rule - this is an enterprise-edition feature not present in standard open-source LiteLLM installations. Network access to the Completions Interface endpoint is required (AV:N). The bypass mechanism operates through manipulation of the prompt argument, suggesting the filter evaluates a normalized or pre-processed representation that diverges from the actual value forwarded to the backend. Exploitation is constrained to: (1) LiteLLM versions 1.82.0-1.82.5, (2) enterprise deployments with the banned_keywords hook enabled, and (3) users holding valid API credentials. Unauthenticated attackers cannot exploit this vulnerability.

The CVSS 4.0 score of 2.1 with vector AV:N/AC:L/AT:N/PR:L/UI:N/VC:L/VI:L/VA:L and supplemental metric E:P reflects a low-to-moderate base risk: network-reachable, low complexity, but requiring authenticated (low-privileged) access, with limited CIA impacts. The E:P metric confirms a public PoC exists, collapsing the gap between theoretical and practical exploitability. No CISA KEV listing is present in the input data, so widespread in-the-wild exploitation is not confirmed. EPSS data was not provided, leaving exploitation probability unquantifiable from this dataset. The low CVSS score should not be interpreted as uniformly low organizational risk: deployments that enforce banned keywords as a compliance control (e.g., preventing policy-violating prompts in regulated environments, blocking prompt-injection attempts, or enforcing data handling constraints) face disproportionately higher business risk than the base score implies. The attack requires an existing authenticated session, which limits opportunistic exploitation but does not protect against insider threats or credential-compromised accounts.

An authenticated low-privileged API user targeting an enterprise LiteLLM 1.82.x deployment submits a Completions API request with a crafted prompt argument - for example, using encoding variations, whitespace injection, or structural manipulation - that causes async_pre_call_hook to incorrectly authorize the request despite its content matching a configured banned keyword. The hook passes the request upstream to the LLM provider, which returns a completion based on content that the enterprise policy was explicitly configured to block. A public proof-of-concept demonstrating this technique is available at https://gist.github.com/YLChen-007/078179224f07cc4e39e4f141a18c817a.