CVE-2026-59823: LiteLLM Proxy has server-side request forgery via the `user_config` request parameter

is_request_body_safe in the proxy rejects the top-level api_base and base_url parameters. It inspected only those two keys. The user_config object carries a full router configuration, and the proxy uses it to build the outbound router for the request. A caller who nests api_base inside user_config bypasses the check and steers the request to any host.

The attacker needs a valid virtual key, so this is an insider or leaked-key problem, not an anonymous one. The result is server-side request forgery: the proxy sends requests, from its own network position, to internal or external hosts the caller cannot reach directly. That can mean internal APIs, admin panels or cloud metadata services reachable from the proxy host. The advisory does not say whether response bodies come back to the caller.

The CVSS 4.0 vector rates confidentiality impact low, which fits a request-steering flaw that needs authentication. Teams that hand out virtual keys to many users or applications are the exposed group.

litellm 1.83.8 and earlier, when the proxy server is in use and callers hold virtual keys. The library used only as an SDK, without the proxy, does not run this request-body guard.

pip show litellm

For Docker, check the image tag you pull; versions at or below 1.83.8 are in range.

Upgrade to litellm 1.83.9, released 2026-04-17:

pip install --upgrade litellm==1.83.9

The fix (pull request 25827) adds user_config to banned_params in is_request_body_safe() in litellm/proxy/auth/auth_utils.py. It is now gated by allow_client_side_credentials, the setting that already governs api_base and base_url. Leave that setting off unless you need clients to send their own credentials; where it is on, clients are allowed to send these parameters by design. Restrict egress from the proxy host to the model providers you use.

Check proxy request logs for request bodies that contain a user_config object, particularly with a nested api_base. Look at proxy egress logs for connections to hosts that are not your configured model providers, such as internal IPs or link-local addresses. Review which virtual keys made those requests, then rotate or revoke them.

Summary

A server-side request forgery in LiteLLM Proxy lets an authenticated caller redirect the proxy's outbound request to a host of their choosing by smuggling an api_base inside the user_config request body, bypassing the existing parameter guard.

Details

LiteLLM Proxy validates request bodies with is_request_body_safe, which blocks the api_base and base_url parameters but does not cover user_config. The user_config object is used to build the outbound router for a request, so a caller can place an api_base inside it and reach an arbitrary host. The guard only inspected the two top-level keys, so the same api_base nested inside user_config was never checked.

Exploitation requires a valid virtual key.

Impact

An authenticated caller can make the proxy issue server-side requests to internal or external hosts of their choosing, reaching endpoints the caller cannot otherwise access.

Affected / Patched

Affected: <= 1.83.8 Patched: 1.83.9

Remediation

Upgrade to 1.83.9 or later (released 2026-04-17).