Description

LiteLLM is a proxy server (AI Gateway) to call LLM APIs in OpenAI (or native) format. Prior to versions 1.88.6 and 1.96.2, any authenticated LiteLLM proxy user could redirect an outbound provider call to a destination the user controls and cause the proxy to send its configured provider credentials to that destination. Request validation in litellm/proxy/auth/auth_utils.py, litellm/proxy/common_request_processing.py, litellm/proxy/health_endpoints/_health_endpoints.py, litellm/proxy/image_endpoints/endpoints.py, and litellm/proxy/litellm_pre_call_utils.py used incomplete checks that did not cover every sensitive parameter or inspect equivalent values across nested request fields, path values, and bracket-notation form data. Routing and credential parameters including api_base, base_url, model_list, fallbacks, and litellm_credential_name could therefore be applied without clearing the operator's stored key, exposing upstream provider credentials and other configured secrets and permitting server-side requests to internal services reachable by the proxy. This issue is fixed in versions 1.88.6 and 1.96.2.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "6.5",
  "pubDate": "2026-09-02T18:21:28.997Z",
  "pubdate": "2026-09-02T18:21:28.997Z",
  "executiveSummary": "LiteLLM versions prior to 1.88.6 and 1.96.2 contain a critical vulnerability that permits authenticated users to perform unauthorized outbound request redirection. This vulnerability, classified as a security misconfiguration or improper input validation, allows an attacker to manipulate request parameters to route traffic to arbitrary, attacker-controlled endpoints.\nBy overriding configuration parameters such as 'api_base' or 'base_url', an authenticated user can force the proxy to transmit sensitive upstream provider credentials and configuration secrets to an external, malicious destination. Furthermore, this capability enables Server-Side Request Forgery (SSRF) patterns, allowing the proxy to be leveraged as a pivot point to interact with internal services residing within the proxy's network segment.\nThe risk to the organization is significant, as it leads to potential credential harvesting of LLM API keys and unauthorized access to internal infrastructure. Exploitation requires the attacker to possess a valid authentication token for the LiteLLM proxy. Given the sensitivity of the exposed credentials, this vulnerability poses a high threat to the confidentiality and integrity of integrated AI services.",
  "technicalDetails": "The root cause of the vulnerability lies in inadequate request validation within critical proxy modules, specifically: 'litellm/proxy/auth/auth_utils.py', 'litellm/proxy/common_request_processing.py', 'litellm/proxy/health_endpoints/_health_endpoints.py', 'litellm/proxy/image_endpoints/endpoints.py', and 'litellm/proxy/litellm_pre_call_utils.py'. The implemented security checks were incomplete and failed to sanitize or validate sensitive parameters when processed through varied input vectors.\nAttackers can leverage this deficiency by injecting malicious values into request payloads, specifically targeting configuration-sensitive fields including 'api_base', 'base_url', 'model_list', 'fallbacks', and 'litellm_credential_name'. The vulnerability persists due to a failure to properly inspect equivalent values across nested request fields, URL path segments, and bracket-notation form data. This bypasses the validation logic intended to ensure that outbound requests adhere to the server's pre-configured, secure routing policies.\nThe attack flow follows a structured exploitation path: first, an authenticated user identifies that the proxy fails to scrub or validate parameter overrides. Second, the user constructs an API request containing a manipulated 'base_url' or equivalent parameter pointing to an attacker-controlled listener. Third, when the LiteLLM proxy processes the request, it utilizes the user-supplied destination instead of the intended legitimate provider API. During the execution of this outbound request, the proxy appends the stored, sensitive provider credentials (configured in the environment or database) to the headers or payload of the request sent to the attacker's server.\nBeyond credential theft, the ability to specify arbitrary host destinations facilitates SSRF. If the LiteLLM proxy operates within a protected internal network, an attacker can route requests to local loopback addresses or non-public internal microservices, potentially accessing management consoles or internal APIs that trust requests coming from the proxy's IP. The failure to clear sensitive operator keys before processing these redirected calls ensures the successful transmission of high-value secrets to the unauthorized destination. This vulnerability affects all LiteLLM proxy deployments below version 1.88.6 and 1.96.2, requiring immediate patching to ensure that request validation logic strictly enforces origin and destination sanitization."
}