CVE-2024-6587 Overview
CVE-2024-6587 is a Server-Side Request Forgery (SSRF) vulnerability in berriai/litellm version 1.38.10. The flaw allows clients to control the api_base parameter when calling POST /chat/completions. LiteLLM forwards the request, including the configured OpenAI API key, to the attacker-controlled domain. An attacker can capture the OpenAI API key and reuse it for unauthorized access to the model provider. The vulnerability is tracked as CWE-918: Server-Side Request Forgery.
Critical Impact
Remote, unauthenticated attackers can redirect LiteLLM outbound requests to an arbitrary host and exfiltrate the configured OpenAI API key, leading to credential theft and downstream API misuse.
Affected Products
- berriai/litellm version 1.38.10
- LiteLLM proxy deployments exposing /chat/completions to untrusted users
- Applications embedding LiteLLM as an LLM gateway with shared upstream API keys
Discovery Timeline
- 2024-09-13 - CVE-2024-6587 published to NVD
- 2024-09-20 - Last updated in NVD database
Technical Details for CVE-2024-6587
Vulnerability Analysis
LiteLLM acts as a proxy that forwards inference requests to upstream model providers such as OpenAI. The /chat/completions endpoint accepts JSON parameters that influence routing, including api_base and base_url. In version 1.38.10, the proxy honors a client-supplied api_base without validating that it matches an allowed upstream host. When the proxy issues the outbound HTTPS request, it attaches the server's configured OpenAI API key as a bearer credential. Redirecting the request to an attacker-controlled domain therefore leaks the secret to that domain.
The issue is classified under CWE-918. EPSS data indicates a high probability of exploitation activity for this CVE.
Root Cause
The proxy trusted user-supplied routing parameters in the request body. The handler in litellm/proxy/auth/auth_checks.py did not enforce an allowlist of upstream hosts or strip dangerous override fields before constructing the outbound call. Any caller able to reach /chat/completions could redirect the request and the attached credential.
Attack Vector
Exploitation requires only network access to a vulnerable LiteLLM endpoint. The attacker sends a chat completion request with api_base set to a host they control. LiteLLM then performs an outbound POST to that host, including the Authorization: Bearer <OPENAI_API_KEY> header. The attacker's server logs the inbound request, extracts the key, and replays it directly against OpenAI under the victim's billing account.
all_routes = LiteLLMRoutes.openai_routes.value + LiteLLMRoutes.management_routes.value
+def is_request_body_safe(request_body: dict) -> bool:
+ """
+ Check if the request body is safe.
+
+ A malicious user can set the api_base to their own domain and invoke POST /chat/completions to intercept and steal the OpenAI API key.
+ Relevant issue: https://huntr.com/bounties/4001e1a2-7b7a-4776-a3ae-e6692ec3d997
+ """
+ banned_params = ["api_base", "base_url"]
+
+ for param in banned_params:
+ if param in request_body:
+ raise ValueError(f"BadRequest: {param} is not allowed in request body")
+
+ return True
+
+
def common_checks(
request_body: dict,
team_object: Optional[LiteLLM_TeamTable],
Source: berriai/litellm commit ba1912a. The patch introduces is_request_body_safe, which rejects any request containing api_base or base_url before the proxy issues the outbound call.
Detection Methods for CVE-2024-6587
Indicators of Compromise
- Outbound HTTPS connections from LiteLLM hosts to domains other than api.openai.com or other approved providers.
- Inbound POST /chat/completions requests whose JSON body contains an api_base or base_url field.
- OpenAI usage records showing requests from unexpected source IP addresses or geographies.
- Sudden growth in OpenAI billing or rate-limit errors that do not correlate with legitimate traffic.
Detection Strategies
- Inspect reverse-proxy or WAF logs for chat completion bodies containing api_base or base_url keys.
- Correlate LiteLLM access logs with egress proxy logs to identify requests where the upstream destination diverges from the configured provider.
- Alert on DNS resolutions from LiteLLM workloads to domains outside an approved upstream allowlist.
Monitoring Recommendations
- Forward LiteLLM application logs and egress NetFlow to a centralized analytics platform and baseline normal upstream destinations.
- Track OpenAI API key usage at the provider side using key-level usage dashboards and budget alerts.
- Monitor the berriai/litellm package version installed in production images and flag any host still on 1.38.10 or earlier.
How to Mitigate CVE-2024-6587
Immediate Actions Required
- Upgrade berriai/litellm to a version that includes commit ba1912a or later, which rejects api_base and base_url in request bodies.
- Rotate any OpenAI API keys and other upstream provider keys configured in LiteLLM deployments that were exposed to untrusted callers.
- Restrict network access to the LiteLLM proxy so only authenticated, trusted clients can reach /chat/completions.
- Enforce egress filtering from LiteLLM hosts to permit only approved model-provider endpoints.
Patch Information
The fix is committed in berriai/litellm commit ba1912afd1b19e38d3704bb156adf887f91ae1e0. The patch adds is_request_body_safe in litellm/proxy/auth/auth_checks.py, which raises an error if the request body contains api_base or base_url. Additional context is available in the Huntr advisory.
Workarounds
- Place a reverse proxy or API gateway in front of LiteLLM that strips api_base and base_url from incoming JSON bodies before they reach the proxy.
- Apply egress allowlisting at the firewall or service mesh level so LiteLLM can only connect to sanctioned model-provider hostnames.
- Issue per-tenant or per-route keys with strict spend limits to reduce the blast radius if a key is exfiltrated before patching.
# Upgrade litellm and verify the patched function exists
pip install --upgrade litellm
python -c "from litellm.proxy.auth.auth_checks import is_request_body_safe; print(is_request_body_safe.__doc__)"
# Reject api_base / base_url at the edge (NGINX example)
# location /chat/completions {
# if ($request_body ~* "\"(api_base|base_url)\"") { return 400; }
# proxy_pass http://litellm_upstream;
# }
Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.


