CVE-2024-4890

Executive Summary

CVE-2024-4890 is a blind SQL injection vulnerability discovered in the BerriAI LiteLLM application, specifically within the /team/update endpoint. The flaw resides in the improper sanitization of the user_id parameter during a raw SQL query used for user deletion. An authenticated attacker with high privileges can inject malicious SQL commands, leading to unauthorized extraction of sensitive data such as API keys, user credentials, and tokens. The vulnerability affects version 1.27.14, and no official patch has been released at the time of analysis. The CVSS score of 4.9 reflects a medium severity due to the requirement of high privileges, but the potential impact on data confidentiality is significant.

Supply Chain & Package Security

LiteLLM is a Python package distributed via PyPI. Organizations using this package should verify their dependency version and monitor for updates. The lack of a patch increases supply chain risk, as the vulnerable component may be integrated into larger systems without immediate remediation.

CVSS Breakdown & Threat Level

• Attack Vector (AV): Network (N) – The vulnerability is exploitable remotely.
• Attack Complexity (AC): Low (L) – No special conditions are required.
• Privileges Required (PR): High (H) – An attacker must have authenticated access with team update privileges.
• User Interaction (UI): None (N) – No user action is needed.
• Scope (S): Unchanged (U) – The exploit does not affect other components.
• Confidentiality (C): High (H) – Sensitive data like API keys and tokens can be exfiltrated.
• Integrity (I): None (N) – Data integrity is not directly compromised.
• Availability (A): None (N) – Service availability is not affected.

Threat Level: Medium. While the CVSS score is 4.9, the potential for data exfiltration in a production environment elevates the risk. The blind SQL injection nature makes exploitation more challenging but still feasible.

Deep Dive & Mechanics

The vulnerability exists in the /team/update endpoint of LiteLLM. When processing a team update request, the application constructs a raw SQL query to delete users from the team. The user_id parameter is directly concatenated into the SQL statement without proper sanitization or parameterization. This allows an attacker to inject arbitrary SQL commands.

The injection is blind, meaning the attacker does not receive direct error messages or query results. Instead, they must infer information based on application behavior (e.g., response times or boolean responses). The attacker can use techniques like AND 1=1 vs AND 1=2 to extract data character by character.

The vulnerable code path likely resembles:

cursor.execute(f"DELETE FROM team_users WHERE team_id = ? AND user_id = {user_id}")

The user_id parameter is interpolated directly, enabling SQL injection.

Vulnerable vs. Patched Code

Vulnerable Code (1.27.14):

# Vulnerable: user_id is directly interpolated
def delete_user_from_team(team_id, user_id):
    cursor.execute(f"DELETE FROM team_users WHERE team_id = ? AND user_id = {user_id}")

Patched Code (Hypothetical):

# Patched: user_id is parameterized
def delete_user_from_team(team_id, user_id):
    cursor.execute("DELETE FROM team_users WHERE team_id = ? AND user_id = ?", (team_id, user_id))

The fix involves using parameterized queries or prepared statements to ensure user input is treated as data, not executable code.

Exploitation & Lab Setup

Red Team (Attack Simulation)

Prerequisites:

• Access to a LiteLLM instance (version 1.27.14)
• Valid credentials with team update privileges
• Knowledge of a valid team ID

Exploitation Steps:

1. Intercept the /team/update request using a proxy like Burp Suite.
2. Identify the user_id parameter in the request body.
3. Inject a blind SQL injection payload to extract data. For example, to check if the first character of an API key is 'a':

   user_id=1' AND SUBSTRING((SELECT api_key FROM api_keys LIMIT 1),1,1)='a'--
   

4. Observe response differences (e.g., success vs. error) to infer true/false conditions.
5. Automate the extraction using a script (e.g., Python with requests library).

Example Python Script:

import requests

url = "http://target:8000/team/update"
cookies = {"session": "valid_session_cookie"}
data = {"team_id": "1", "user_id": "1' AND 1=1--"}
response = requests.post(url, cookies=cookies, data=data)
print(response.status_code)

Blue Team (Defense & Detection)

Detection Strategy:

• Monitor for unusual SQL error patterns in application logs.
• Implement Web Application Firewall (WAF) rules to block SQL injection patterns.
• Use database activity monitoring to detect anomalous queries.

Honeypot Setup:

• Deploy a decoy LiteLLM instance with fake data to lure attackers.
• Log all requests to /team/update and analyze for injection attempts.

Indicators of Compromise (IOCs)

• Network IOCs:
  • HTTP POST requests to /team/update with abnormal user_id values containing SQL keywords (e.g., ', --, UNION, SELECT).
  • Repeated requests with slight variations in user_id (blind injection attempts).
• Log IOCs:
  • Database error logs containing SQL syntax errors from injected queries.
  • Application logs showing failed authentication attempts followed by successful team updates.
• File IOCs:
  • Temporary files or scripts used for automated extraction (e.g., exploit.py).

Detection Engineering

YARA Rule

rule CVE_2024_4890_SQLi_Detection {
    meta:
        description = "Detects SQL injection attempts targeting CVE-2024-4890 in LiteLLM"
        author = "Valters IT"
        date = "2025-04-10"
        reference = "CVE-2024-4890"
    strings:
        $sqli1 = "user_id="
        $sqli2 = "' OR '1'='1"
        $sqli3 = "UNION SELECT"
        $sqli4 = "AND 1=1"
        $sqli5 = "SUBSTRING("
    condition:
        any of ($sqli*) and filesize < 10KB
}

Sigma Rule

title: CVE-2024-4890 SQL Injection Attempt
id: 12345678-1234-1234-1234-123456789abc
status: experimental
description: Detects SQL injection attempts against LiteLLM /team/update endpoint
author: Valters IT
date: 2025-04-10
logsource:
    category: webserver
    product: apache
detection:
    selection:
        cs-method: 'POST'
        cs-uri-stem: '/team/update'
        cs-uri-query|contains: 
            - 'user_id='
            - "'"
            - '--'
            - 'UNION'
            - 'SELECT'
    condition: selection
falsepositives:
    - Legitimate use of special characters in user IDs (unlikely)
level: high

Suricata Rule

alert http $HOME_NET any -> $EXTERNAL_NET any (
    msg:"CVE-2024-4890 SQL Injection Attempt";
    flow:to_server,established;
    content:"POST"; http_method;
    content:"/team/update"; http_uri;
    content:"user_id"; http_client_body;
    pcre:"/user_id=[^&]*['\-\-]/Pi";
    sid:1000001;
    rev:1;
    reference:cve,2024-4890;
)

Remediation & Mitigation

Immediate Actions:

1. Isolate the affected LiteLLM instance from production networks if possible.
2. Restrict access to the /team/update endpoint to only trusted IPs.
3. Monitor logs for exploitation attempts.

Long-Term Fix:

• Upgrade to a patched version once available.
• Implement parameterized queries in the codebase.
• Conduct a code review for similar injection vulnerabilities.

Workarounds:

• Use a WAF to block SQL injection patterns.
• Apply input validation to ensure user_id is a numeric value (if applicable).

Valters IT