CVE-2026-84377 in LiteLLM
Summary
by MITRE • 09/02/2026
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.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 09/02/2026
The vulnerability identified in LiteLLM prior to versions 1.88.6 and 1.96.2 represents a critical server-side request forgery flaw that allows authenticated users to exfiltrate sensitive provider credentials by manipulating outbound API calls. As an AI gateway or proxy, LiteLLM is designed to abstract the complexity of interacting with various Large Language Model providers, handling authentication and routing on behalf of client applications. The core architectural weakness lies in how the system validates and processes request parameters before forwarding them to upstream LLM APIs. Specifically, the validation logic implemented across multiple components including auth_utils.py, common_request_processing.py, health_endpoints/_health_endpoints.py, image_endpoints/endpoints.py, and litellm_pre_call_utils.py relies on incomplete checks that fail to adequately sanitize or restrict critical routing parameters such as api_base, base_url, model_list, fallbacks, and litellm_credential_name. This insufficiency permits an attacker who has obtained valid authentication credentials for the LiteLLM proxy to redirect outbound traffic intended for legitimate LLM providers toward a destination under their control.
From a technical perspective, this flaw is classified as CWE-918 Server-Side Request Forgery (SSRF) with specific implications for credential exposure and data exfiltration. The vulnerability arises because the application does not strictly validate that the target URL or routing configuration points exclusively to authorized upstream providers. Instead, it allows users to supply arbitrary values for parameters like base_url or api_base without sufficient verification against a whitelist of allowed domains or protocols. Furthermore, the validation logic fails to inspect equivalent values across nested request fields and bracket-notation form data, creating multiple vectors through which an attacker can bypass security controls. By manipulating these parameters, an authenticated user can configure the proxy to send requests containing its configured provider credentials directly to a malicious server they operate. This effectively turns the LiteLLM instance into a tool for credential harvesting, as the upstream LLM API expects standard authentication headers or tokens that are now transmitted in plaintext to the attacker's endpoint rather than being used securely within the intended service context.
The operational impact of this vulnerability is severe, primarily due to the high privilege level associated with authenticated users and the sensitivity of the data exposed. The exposure of upstream provider credentials allows attackers to impersonate legitimate clients when interacting with LLM APIs such as OpenAI or other supported providers. This can lead to unauthorized usage of paid API services, resulting in significant financial loss for the organization running the LiteLLM proxy. Additionally, if the proxy is configured to access internal services reachable by its network environment, the SSRF capability enables further lateral movement and potential compromise of internal infrastructure that would otherwise be isolated from external networks. The ability to redirect requests also facilitates data exfiltration, as any sensitive information processed through these redirected calls could be intercepted or logged by the attacker-controlled destination. This scenario aligns with ATT&CK technique T1589 Gather Victim Identity Information and potentially T1078 Valid Accounts if the initial authentication was obtained via phishing or other means, followed by T1046 Network Service Discovery if internal services are probed through the SSRF vector.
To mitigate this vulnerability, organizations must immediately upgrade to LiteLLM version 1.88.6 or later where these validation checks have been hardened. In addition to upgrading, it is recommended to implement strict allow-listing for all outbound proxy destinations at both the application and network levels. Application-level mitigations should include rigorous validation of base_url and api_base parameters against a predefined list of trusted domains, ensuring that no user-supplied input can override these critical routing configurations without explicit administrative approval. Network-level controls such as egress filtering or firewall rules restricting outbound connections to only known LLM provider endpoints provide an additional layer of defense in depth. Furthermore, adopting the principle of least privilege for LiteLLM users ensures that even if a vulnerability is exploited, the scope of potential damage is limited by reducing the number of parameters and actions available to standard authenticated users rather than administrators. Regular security audits focusing on SSRF vectors in proxy applications are essential to maintain robust security posture against evolving threat landscapes targeting AI infrastructure components.