LiteLLM CVE-2026-84377: Any Proxy Key Could Leak Your Provider Keys

On 30 September 2026, BerriAI published GHSA-3cv6-jpf6-8222 for CVE-2026-84377 in the LiteLLM proxy. Any authenticated proxy user could point an outbound provider call at a host they controlled, and the proxy would send the operator's own provider credentials to that host. The same gap allowed server-side request forgery against internal services reachable from the proxy.

It is rated medium (CVSS 6.5) because it needs a valid proxy key. But the point of LiteLLM's virtual keys is that many teams, apps or customers can hold proxy keys while only the operator holds the upstream provider credentials. This bug collapsed that separation.

What's affected

• Package: litellm on PyPI (the proxy server).
• Fixed releases: 1.88.6, 1.89.7, 1.90.7, 1.91.5, 1.92.2, 1.93.2, 1.94.3, 1.95.1 and 1.96.2. PyPI shows these were uploaded between 9 and 11 August 2026, seven weeks before the advisory.
• Vulnerable: everything below 1.88.6, and each 1.89 to 1.96 line below its fixed patch release. The advisory's ranges don't include 1.97.0 and later, which were released after the fixes. The current release is 1.106.0.

The advisory explains the root cause. The proxy validated request bodies with a denylist. That list didn't cover every sensitive parameter and didn't look inside parameters nested in other request fields. A caller could supply a routing or credential value that the proxy applied without clearing the operator's stored key, so the stored key went to the caller's destination.

This is the second advisory of this shape in a month. On 17 September, GHSA-hx8v-g79f-8w5f (CVE-2026-59823) described the same pattern in miniature: the request guard blocked top-level api_base and base_url but not user_config, which builds the outbound router, so an api_base nested there went through. That one was fixed back in 1.83.9, released 17 April 2026.

How to check if you're exposed

Get the running version from wherever the proxy runs:

pip show litellm | grep -i ^version
docker exec litellm python -c "import importlib.metadata as m; print(m.version('litellm'))"

Compare it with the fixed release for its minor line. For example, 1.94.2 is vulnerable and 1.94.3 is fixed.

Then check how much the bug matters in your deployment. It needs three things:

1. Callers who hold proxy keys but should not see upstream provider keys. If only one trusted service uses the proxy, the exposure is small. If you issue keys to many teams, internal apps or customers, it's large.

2. Client-side credential overrides allowed. Check your config:

   grep -n "allow_client_side_credentials" config.yaml
   

   The advisory's first workaround is setting it to false, so caller-supplied connection parameters are refused.

3. Something worth reaching. The proxy's network position decides the SSRF impact: cloud metadata, internal admin panels, databases on the same VPC.

If you log request bodies at a gateway in front of LiteLLM, search them for routing fields that callers should never send, such as api_base, base_url, model_list, fallbacks and user_config.

What to do now

1. Upgrade to the fixed release on your line, or move to a current release. The advisory's ranges stop at the 1.96 line.
2. Set general_settings.allow_client_side_credentials: false unless you have a specific need for callers to bring their own connection settings.
3. At your reverse proxy or API gateway, strip or reject api_base, base_url, model_list, fallbacks and provider credential fields from client requests. The advisory lists this as a workaround, and it's a sensible permanent control.
4. Rotate upstream provider keys if any untrusted or semi-trusted party held a proxy key while you ran a vulnerable version. You can't tell from the provider side whether a key was copied.
5. Block the proxy's egress to cloud metadata endpoints and internal ranges it has no reason to reach.
6. Review who holds proxy keys. Each key is now a credential that, on an unpatched proxy, was as good as your provider key.

Why it matters

AI gateways exist to centralize provider credentials so that apps don't hold them. That only works if callers can't influence where the gateway sends those credentials. Any request parameter that changes the upstream destination is security-relevant, and a denylist of such parameters will always miss one, especially when the request schema allows nesting.

The fix pattern that holds up is the reverse: an allowlist of fields a caller may set, with destination and credential fields owned by server config only. If you build or run an AI gateway, test it the way these reporters did, by hiding a destination field one level deeper than the guard looks.

Try it yourself

Take one real request your apps send through the proxy and list every field in it that could change where the request goes or which credential it uses. Then see how an API security scan probes for parameter-driven SSRF:

Click through it at your own pace, or open it full screen.

Quick check

Sources

• GHSA-3cv6-jpf6-8222: Authenticated SSRF and provider-credential exfiltration via request-body routing parameters (CVE-2026-84377)
• GHSA-hx8v-g79f-8w5f: Server-side request forgery via the user_config request parameter (CVE-2026-59823)
• GitHub Advisory Database entry for GHSA-3cv6-jpf6-8222
• litellm on PyPI