LiteLLM EUVD-2026-42359

Exploitation requires that the target run LiteLLM proxy prior to 1.84.0 with the MCP Streamable HTTP endpoint enabled and reachable by the attacker, and that the OAuth2 passthrough fallback path be present (the pre-1.84.0 default behavior). The concrete trigger is a single request carrying a fabricated/invalid Authorization header that causes LiteLLM key validation to fail and divert into the OAuth2 passthrough branch, which substitutes an empty UserAPIKeyAuth() object. No valid LiteLLM key, credentials, or user interaction are needed (PR:N/UI:N). Exploitation is limited to environments where the MCP endpoint is network-exposed; deployments that do not enable the MCP Streamable HTTP feature or that isolate it behind a separate authenticating layer are not reachable via this specific bypass.

The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:L/VA:N) is internally consistent with the description: an unauthenticated, network-adjacent attacker with low complexity and no user interaction gains high confidentiality impact by reaching MCP tooling that should require a valid key. This is a genuine priority for any deployment that exposes the LiteLLM MCP endpoint to untrusted networks, because auth-bypass-to-tool-access is directly actionable and the fix path (fail-open on validation failure) is trivial to trigger. Tempering factors: no EPSS score, KEV entry, or public POC is present in the provided data, so there is currently no evidence of active or automated exploitation - the signal is 'reachable and severe' rather than 'known-exploited.' Integrity impact is rated Low and availability None, meaning the primary risk is unauthorized access to MCP tools/data rather than destruction; actual blast radius depends on what MCP tools are wired into the gateway. Note that no CVSS 3.1 vector was supplied in the input (only a 4.0 vector and an 8.8 score), so authentication metrics are read from the 4.0 PR:N field.

An attacker who can reach the LiteLLM MCP Streamable HTTP endpoint over the network sends a request with a fabricated Authorization header and no valid LiteLLM key. LiteLLM's key validation fails but falls through to the OAuth2 passthrough branch, granting an empty authenticated context, and the attacker's request is passed to the backing MCP tools. No POC is referenced in the provided data, but given AC:L and no required user interaction, crafting the malicious header is straightforward.