SSRF via user_config in LiteLLM Proxy
LiteLLM Proxy versions before 1.83.9 contain a server-side request forgery vulnerability in the Clientside LLM Credentials feature. The is_request_body_safe function blocks top-level api_base and base_url parameters but does not inspect or reject routing destinations nested within user_config. An authenticated caller holding a valid virtual key can submit user_config containing a model_list with attacker-selected api_base values. Because LiteLLM constructs an outbound router from this configuration, subsequent inference requests can be directed to arbitrary internal or external hosts, bypassing destination restrictions and potentially exposing provider credentials attached to forwarded requests.
What it means and what to do now: patch path, interim mitigations, and the assume-compromise checklist.
What an attacker gets, and what they’ve been doing with it.
Authenticated users can make requests from the gateway to network endpoints they cannot access directly, enabling internal network probing and potential exposure of internal services. Redirecting inference traffic to an attacker-controlled server can disclose request contents and AI provider API keys when those credentials are included in forwarded headers. Stolen provider keys can enable unauthorized use of organizational AI accounts and associated charges.
If you can’t patch tonight, do this now.
Until upgraded, restrict virtual-key issuance and proxy access to trusted users and revoke unnecessary keys. Apply outbound network controls that allow only approved provider destinations and deny access to sensitive internal services and instance metadata endpoints. Block untrusted user_config routing overrides, including nested api_base values; monitoring only top-level destination parameters does not address this bypass.
Patch, then assume compromise.
Upgrade the litellm package and LiteLLM Proxy to version 1.83.9 or later, including deployments embedded in other platforms or internal tools. If unauthorized access or request redirection is suspected, rotate potentially exposed AI provider API keys and review gateway access and request logs.
No public exploits tracked yet. Mallory keeps watching.
Products and vendors Mallory has correlated with this vulnerability. Open in Mallory to drill down to specific CPE configurations and version ranges.
14 sources tracked across advisories, community write-ups, and news. New activity surfaces here as Mallory finds it.