BerriAI LiteLLM CVE-2026-12770

Exploitation requires a valid authenticated LiteLLM API key with at minimum standard user privileges - the CVSS 4.0 vector confirms PR:L (low-privilege authentication required). The attacker must have network access to the LiteLLM proxy management API. Three specific privileged operations are exploitable without admin authorization: (1) blocking any API key via POST /key/block, (2) unblocking any API key via POST /key/unblock, and (3) modifying the max_budget field of any key via POST /key/update. No special configuration, non-default deployment mode, or specific platform is required - any standard LiteLLM proxy deployment on versions 1.63.0 or 1.63.1 with the management API exposed is vulnerable. The primary factor limiting exploitation is the PR:L requirement: an attacker without any valid API key credential cannot exploit this vulnerability. Legitimate single-tenant deployments where all users are fully trusted face negligible practical risk despite the technical flaw.

The official CVSS 4.0 score of 2.1 significantly underrepresents real-world operational risk for multi-tenant LiteLLM deployments. The score is depressed by the low magnitude impact metrics (VI:L/VA:L/VC:N) and PR:L, but in a shared LiteLLM gateway serving multiple teams or organizations, an authenticated attacker can selectively disable competitors' API keys (availability disruption), restore suspended keys that administrators intentionally blocked (integrity violation of policy enforcement), or manipulate budget caps to either exhaust or inflate spending limits. The CVSS 4.0 threat metric E:P confirms a proof-of-concept exists, elevating urgency despite the low base score. No EPSS score was available in the provided intelligence; no CISA KEV listing exists, indicating exploitation is not yet confirmed as widespread. Risk is concentrated in SaaS-style or multi-tenant LiteLLM deployments; single-tenant instances with a small, fully trusted user base face substantially lower risk. The PR:L prerequisite is the primary limiting factor - an unauthenticated external attacker cannot exploit this without first obtaining a valid API key.

An authenticated LiteLLM user holding any standard (non-admin) API key identifies the hashed token of a target user's key - obtainable through normal API responses or shared deployment artifacts - and sends a crafted POST request to /key/block with the target token. Because the authorization check was absent in versions 1.63.0-1.63.1, the request succeeds and the target key is immediately blocked, denying that user API access. The publicly available PoC at https://gist.github.com/YLChen-007/993c68152b2c770d53590f1684c755d4 demonstrates this exact sequence.