CVE-2026-84377: LiteLLM: Authenticated SSRF and provider-credential exfiltration via unvalidated request-body routing parameters

The proxy filtered sensitive request-body fields with a denylist. The list missed some parameters and did not look inside parameters nested in other request fields. A caller could therefore supply a routing or credential value, such as api_base, base_url, model_list, fallbacks or a provider credential field, that the proxy applied without clearing the operator's stored key. The proxy then sent the real upstream key to the attacker-chosen destination.

An attacker needs only a valid proxy key, any key, since the CVSS vector requires low privileges. A single chat or completion request with an attacker-controlled api_base is enough. The outcomes are theft of the operator's upstream provider credentials and other configured secrets, and server-side requests to internal services reachable from the proxy host. The advisory does not claim code execution.

This matters most where one LiteLLM proxy is shared by many teams or applications and virtual keys are handed out widely, because every key holder becomes able to take the master provider credentials.

litellm below 1.88.6, and each affected line: 1.89.0 to before 1.89.7, 1.90.0 to before 1.90.7, 1.91.0 to before 1.91.5, 1.92.0 to before 1.92.2, 1.93.0 to before 1.93.2, 1.94.0 to before 1.94.3, 1.95.0 to before 1.95.1, and 1.96.0 to before 1.96.2. The risk applies to LiteLLM proxy deployments with more than one caller.

pip show litellm

Upgrade to the patched release for your line: 1.96.2, 1.95.1, 1.94.3, 1.93.2, 1.92.2, 1.91.5, 1.90.7, 1.89.7 or 1.88.6.

pip install -U litellm

Workarounds from the advisory:

• Set general_settings.allow_client_side_credentials to false so callers cannot override connection parameters.
• Restrict proxy keys to trusted callers.
• Block api_base, base_url, model_list, fallbacks and provider credential fields at a reverse proxy or API gateway.

If an untrusted user held a key before you patched, rotate the upstream provider keys.

Review proxy request logs for bodies that contain api_base, base_url, model_list, fallbacks or credential fields sent by ordinary virtual keys. Check network egress from the proxy host for connections to hosts that are not your configured providers, and for requests to internal addresses. Check your upstream provider dashboards for key use from unfamiliar IPs. Rotate the provider keys if any of this shows up.

Impact

Any authenticated LiteLLM proxy user could redirect an outbound provider call to a destination they control and cause the proxy to send its own configured provider credentials to that destination. The proxy's request-body validation was a denylist that did not cover every sensitive parameter and did not inspect parameters nested inside other request fields, so a caller could supply a routing or credential value that the proxy applied without clearing the operator's stored key. Any authenticated user could therefore exfiltrate the operator's upstream provider credentials and other configured secrets, and perform Server-Side Request Forgery against internal services reachable from the proxy.

Patches

Fixed in 1.96.2, 1.95.1, 1.94.3, 1.93.2, 1.92.2, 1.91.5, 1.90.7, 1.89.7, and 1.88.6.

Workarounds

Set general_settings.allow_client_side_credentials to false so callers cannot override connection parameters, restrict proxy keys to trusted callers, and block the affected parameters (api_base, base_url, model_list, fallbacks, provider credential fields) at a reverse proxy or API gateway.