CVE-2026-59823 in LiteLLM
Summary
by MITRE • 09/17/2026
LiteLLM is a proxy server (AI Gateway) to call LLM APIs in OpenAI (or native) format. Prior to 1.83.9, an authenticated LiteLLM Proxy caller with a valid virtual key can place api_base inside the user_config request body to bypass is_request_body_safe, which blocks top-level api_base and base_url but previously did not inspect or reject user_config. Because user_config constructs the outbound router, the nested destination redirects a server-side request to an internal or external host selected by the caller and can expose endpoints the caller cannot otherwise access. This issue is fixed in version 1.83.9.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 09/17/2026
The vulnerability identified in LiteLLM versions prior to 1.83.9 represents a critical server-side request forgery flaw within an AI gateway proxy architecture. LiteLLM functions as an intermediary layer that normalizes requests from various large language model providers into a unified OpenAI-compatible format, facilitating secure and standardized API interactions for downstream applications. The core security mechanism in place is the is_request_body_safe validation function, which is designed to sanitize incoming request payloads by blocking potentially dangerous top-level fields such as api_base or base_url that could redirect outbound traffic to malicious destinations. However, this sanitization logic was incomplete because it failed to recursively inspect nested configuration objects within the user_config parameter of the request body.
An authenticated attacker possessing a valid virtual key can exploit this oversight by embedding an api_base directive inside the user_config object rather than at the top level of the JSON payload. Since the validation routine only checks the root level, it permits the submission of these malicious configurations without triggering any security alerts or rejection mechanisms. Once accepted, the LiteLLM proxy processes the user_config to construct the outbound router for the API call. This allows the attacker to dictate the destination host and port for the proxied request, effectively bypassing the intended access controls that restrict which endpoints can be reached through the gateway.
The operational impact of this vulnerability is significant due to its potential for both internal network reconnaissance and external data exfiltration. By redirecting server-side requests to arbitrary hosts, an attacker can probe internal services that are not exposed to the public internet but are accessible from the proxy server's network interface. This includes accessing administrative panels, database endpoints, or other microservices running on private subnets. Furthermore, if the proxy has access to external resources, the attacker could force the gateway to make requests to maliciously controlled servers, potentially leading to data leakage through side channels or enabling further attacks against third-party services via SSRF-based amplification techniques.
This flaw aligns with CWE-918 Server-Side Request Forgery (SSRF), specifically illustrating how improper input validation of nested structures can lead to unauthorized network access. It also maps to the MITRE ATT&CK technique T1557, which covers Adversary-in-the-Middle scenarios where an attacker intercepts and manipulates communications between two parties. In this context, the proxy acts as a conduit that is manipulated by the adversary to establish connections with unintended targets, compromising the integrity of the network segmentation strategy employed around the AI gateway infrastructure.
To mitigate this vulnerability, organizations must immediately upgrade LiteLLM to version 1.83.9 or later, where the validation logic has been updated to recursively inspect and sanitize all nested fields within user_config for dangerous directives like api_base. In environments where upgrading is not immediately feasible, network-level controls should be implemented to restrict the outbound traffic from the proxy server to only known and trusted endpoints using firewall rules or egress filtering policies. Additionally, implementing strict allow-listing of permitted LLM providers in the gateway configuration can reduce the attack surface by preventing dynamic destination overrides entirely for untrusted users. Regular auditing of authentication mechanisms and virtual key permissions is also recommended to ensure that access rights are granted on a least-privilege basis, minimizing the potential impact if an account credential is compromised.