CVE-2026-59823: LiteLLM Proxy Server SSRF Vulnerability

CVE-2026-59823 Overview

CVE-2026-59823 is a Server-Side Request Forgery (SSRF) vulnerability in LiteLLM, an AI Gateway proxy server that routes LLM API calls in OpenAI-compatible format. The flaw allows any authenticated caller holding a valid virtual key to bypass the is_request_body_safe guardrail by nesting api_base inside the user_config request body. Because user_config builds the outbound router, the caller can redirect server-side requests to arbitrary internal or external hosts. The issue is tracked as [CWE-918] and is fixed in LiteLLM version 1.83.9.

Critical Impact
Authenticated attackers can pivot the LiteLLM Proxy into internal networks, reach endpoints the caller cannot otherwise access, and potentially intercept upstream API credentials.

Affected Products

LiteLLM (BerriAI) versions prior to 1.83.9
LiteLLM Proxy deployments accepting virtual keys from multiple tenants
Self-hosted AI gateways built on LiteLLM router configuration

Discovery Timeline

2026-09-16 - CVE-2026-59823 published to NVD
2026-09-16 - Last updated in NVD database

Technical Details for CVE-2026-59823

Vulnerability Analysis

LiteLLM Proxy exposes an OpenAI-compatible endpoint that forwards chat, completion, and embedding requests to upstream model providers. To prevent tenants from redirecting traffic to attacker-controlled hosts, the proxy runs is_request_body_safe, which rejects any request containing top-level api_base or base_url parameters. This mitigation was originally added in response to a prior report where a malicious caller could set api_base to their own domain and steal the upstream OpenAI API key.

The check only inspected the outermost keys of the request body. The user_config field, however, accepts a nested object that LiteLLM uses to construct the outbound router at request time. Any api_base value placed inside user_config was accepted and used to build the destination URL for the server-side HTTP call. An authenticated tenant could therefore point requests at internal services, cloud metadata endpoints, or arbitrary external hosts.

Root Cause

The denylist in litellm/proxy/auth/auth_utils.py enumerated only api_base and base_url at the top level. It did not recursively walk user_config, so an equivalent nested key bypassed the guardrail entirely. The fix adds user_config to the banned parameter list.

Attack Vector

Exploitation requires network access to the proxy and a valid virtual key (PR:L). The attacker crafts a normal chat completion request, embeds a user_config object containing api_base pointing at an internal or attacker-controlled host, and submits it to the proxy. The proxy builds a router from user_config and issues the outbound request to the caller-controlled destination, returning the response body to the caller.

python

# Patch: litellm/proxy/auth/auth_utils.py
# fix(proxy): harden request parameter handling
#
# A malicious user can set the api_base to their own domain and invoke
# POST /chat/completions to intercept and steal the OpenAI API key.
# Relevant issue: https://huntr.com/bounties/4001e1a2-7b7a-4776-a3ae-e6692ec3d997

-    banned_params = ["api_base", "base_url"]
+    banned_params = ["api_base", "base_url", "user_config"]

    for param in banned_params:
        if (
            ...
        ):

Source: BerriAI/litellm commit 47214be

Detection Methods for CVE-2026-59823

Indicators of Compromise

Requests to LiteLLM Proxy endpoints (/chat/completions, /completions, /embeddings) containing a user_config key in the JSON body.
Outbound HTTP requests from the LiteLLM Proxy host to RFC1918 addresses, cloud metadata IPs (169.254.169.254), or unexpected external domains.
Virtual key usage patterns showing repeated requests with varying api_base values inside nested config objects.

Detection Strategies

Enable request-body logging on the reverse proxy in front of LiteLLM and alert on any body containing the substring "user_config" combined with "api_base" or "base_url".
Correlate LiteLLM access logs with egress firewall logs to identify outbound calls that do not match the configured upstream model providers.
Hunt for anomalous 200 responses whose upstream destination differs from the tenant's assigned model routing configuration.

Monitoring Recommendations

Instrument the proxy container with egress allow-lists restricted to known LLM provider domains; alert on denied connections.
Monitor for spikes in per-key request diversity that suggest SSRF probing of internal address space.
Track the deployed LiteLLM version and alert if any node reports a release earlier than 1.83.9.

How to Mitigate CVE-2026-59823

Immediate Actions Required

Upgrade LiteLLM to version 1.83.9 or later on every proxy node.
Rotate any upstream provider API keys stored in LiteLLM configuration, since prior requests may have exfiltrated them via a redirected api_base.
Rotate all virtual keys and audit issuance to confirm no untrusted tenants retain access.
Review egress firewall rules on proxy hosts and restrict outbound traffic to approved LLM provider endpoints only.

Patch Information

The fix is delivered in LiteLLM 1.83.9 via Pull Request #25827 and commit 47214be. The patch adds user_config to the banned_params list in is_request_body_safe and introduces an internal ContextVar mechanism so trusted internal sub-calls cannot be spoofed through HTTP bodies. Full details are in GitHub Security Advisory GHSA-hx8v-g79f-8w5f.

Workarounds

If immediate upgrade is not possible, deploy a WAF rule that rejects any request body containing user_config with nested api_base or base_url keys.
Restrict virtual key issuance to trusted tenants only until the patched version is deployed.
Place the LiteLLM Proxy behind a network policy that blocks outbound traffic to internal CIDRs and cloud metadata services.

bash

# Example: pin LiteLLM to the patched release
pip install --upgrade 'litellm>=1.83.9'

# Verify running version
python -c "import litellm; print(litellm.__version__)"

# Example egress allow-list (iptables) restricting proxy host to known providers
iptables -A OUTPUT -d api.openai.com -p tcp --dport 443 -j ACCEPT
iptables -A OUTPUT -d api.anthropic.com -p tcp --dport 443 -j ACCEPT
iptables -A OUTPUT -m addrtype --dst-type PRIVATE -j REJECT
iptables -A OUTPUT -d 169.254.169.254 -j REJECT