litellm vulnerable to remote code execution based on using eval unsafely

The impact of CVE-2024-5751 is severe. A successful exploit grants an attacker complete control over the affected litellm server. This can lead to data breaches, system compromise, and potential lateral movement within the network. The attacker can read, modify, or delete sensitive data, install malware, or use the server as a launchpad for further attacks. The requirement for Google KMS and database storage means that deployments relying on these components are particularly vulnerable. The ability to inject arbitrary code directly into the server's environment represents a significant security risk, potentially allowing for persistent access and control.

Organizations utilizing litellm for LLM deployment, particularly those relying on Google KMS for key management and a database for model storage, are at significant risk. Shared hosting environments where multiple users share the same server instance are also vulnerable, as an attacker could potentially exploit the vulnerability through another user's access to the /config/update endpoint.

• python / server:

import os
import base64

# Check environment variables for suspicious base64 encoded data
for key, value in os.environ.items():
    try:
        decoded_value = base64.b64decode(value)
        if len(decoded_value) > 1000: # Arbitrary length check
            print(f"Suspicious base64 encoded data in environment variable: {key}")
    except Exception:
        pass

• linux / server:

# Check for unusual environment variables in process listings
ps aux | grep -i 'base64' | grep -i 'config/update'

• generic web:

curl -I <litellm_server_url>/config/update
# Look for unusual headers or request parameters

1. 2024-06-27Disclosure

   disclosure

2. 2024-06-27Patch

   patch

1. Reserviert2024-06-07
2. Veröffentlicht2024-06-27
3. Geändert2024-06-28
4. EPSS aktualisiert2026-04-02

The primary mitigation for CVE-2024-5751 is to immediately upgrade to litellm version 1.40.16 or later. If upgrading is not immediately feasible, consider implementing temporary workarounds. Restrict access to the /config/update endpoint to trusted sources only, using firewall rules or network segmentation. Carefully validate and sanitize any data received through this endpoint. Monitor server logs for suspicious activity, particularly attempts to access or modify environment variables. Consider implementing a Web Application Firewall (WAF) to filter malicious requests targeting the /config/update endpoint. After upgrading, confirm the fix by attempting to send a crafted payload to the /config/update endpoint and verifying that it is rejected.