LiteLLM Proxy SSRF via user_config Parameter Smuggling

Technical Analysis

LiteLLM Proxy's `is_request_body_safe` guard only checks top-level `api_base` and `base_url` keys to prevent SSRF, but the router construction logic also reads `api_base` from within the nested `user_config` object without applying the same validation. An authenticated caller can nest `api_base` inside `user_config` in the request body to bypass the guard entirely, causing the proxy's outbound router to issue requests to attacker-chosen internal or external hosts. This crosses a trust boundary because the proxy acts as an intermediary/agent making privileged network calls on behalf of the model routing layer, and the attacker leverages that trust to reach endpoints (e.g., cloud metadata services, internal APIs) the caller could not otherwise access directly. The entry point is the standard chat/completions request body accepted by any valid virtual key holder, making it exploitable by any tenant in a multi-tenant LiteLLM deployment.

Affected Systems

LiteLLM

Detection Signatures

• Requests containing `user_config` objects with nested `api_base` or `base_url` keys not matching allow-listed model providers
• Proxy outbound connections to unexpected internal IP ranges (e.g., 169.254.169.254, RFC1918 addresses) originating from LiteLLM proxy process
• Anomalous router configuration changes correlated with individual virtual key usage
• Log entries showing router initialization with non-standard api_base values per-request rather than per-deployment config

Remediation Steps

1. 1

   Upgrade LiteLLM Proxy

   Update to version 1.83.9 or later, which extends the request body safety guard to cover nested api_base/base_url fields within user_config.

2. 2

   Restrict virtual key scopes

   Limit which virtual keys are allowed to pass custom user_config or router overrides, especially in multi-tenant environments.

3. 3

   Egress filtering

   Apply network-level egress controls (firewall/proxy rules) so the LiteLLM proxy host cannot reach internal metadata services or sensitive internal endpoints regardless of application-layer validation.

4. 4

   Audit logging

   Log and monitor all outbound requests initiated by the proxy, flagging any api_base values that deviate from configured, allow-listed model provider endpoints.