From Virtual Key to Internal Target: Responding to LiteLLM SSRF
From Virtual Key to Internal Target: Responding to LiteLLM SSRF CVE-2026-59823 starts with a permitted API caller, not an anonymous internet attack. A person holding a LiteLLM virtual key can place api_base inside user
From Virtual Key to Internal Target: Responding to LiteLLM SSRF
CVE-2026-59823 starts with a permitted API caller, not an anonymous internet attack. A person holding a LiteLLM virtual key can place api_base inside user_config, bypass the top-level parameter check, and make the proxy request a chosen host. The gateway's network position turns that permission into a routing problem.
Request chain and failure point
A normal request reaches LiteLLM Proxy, passes through request safety checks, and is routed to a model provider. Here, is_request_body_safe inspected top-level api_base and base_url fields. It missed the nested value in user_config, which router construction consumed.
A caller with a valid virtual key can therefore submit a route configuration that changes the outbound destination. The proxy can contact internal or external hosts that the client cannot reach directly. The advisory rates this CWE-918 issue at CVSS 4.0 score 5.3 with limited confidentiality impact.
What the score omits
The base score gives a common severity, not a complete map of each deployment. An internal gateway with tightly controlled keys may have a small reachable target set. A shared gateway with permissive key issuance and broad cloud network access may reach metadata endpoints, admin services, or internal APIs. The CVE does not expose those services by itself; it gives an authorized caller a different network vantage point.
Access logs, proxy logs, and egress telemetry help reconstruct whether that vantage point was used. Look for user_config containing URL-like values and correlate the request with unusual outbound destinations. Keep model inputs and provider secrets out of broad investigation logs.
Fixed release
LiteLLM versions through 1.83.8 are affected. Version 1.83.9 is fixed. The vendor patch adds user_config to the blocked parameters and separates internal request context from user-controlled fields.
Upgrade every reachable proxy instance and verify the package running. Review virtual keys for unused or excessive rights. Restrict outbound network access to the provider APIs and internal services the gateway requires. If logs show unauthorized access, preserve the evidence and assess whether provider credentials need rotation.
Network exposure context
ZoomEye's app="LiteLLM" query returned 58,420 application-fingerprint matches. The CVE-specific filter returned 0. The product count supports discovery of LiteLLM interfaces, not a claim of confirmed vulnerabilities. An organization needs package, authentication, and network evidence to decide which visible services matter.
Response sequence
The first action is to stop the known vulnerable path with the 1.83.9 upgrade. The second is to reduce the proxy's ability to reach unrelated networks. The third is to compare retained logs for request and egress evidence. These actions address the flaw, limit its leverage, and answer whether investigation is needed. They also make the final report specific about what is known.
References
Originally published by Dev.to Security. Aggregated on AIWithGhost for educational purposes — full credit and traffic to the original publisher.