CVE-2024-5225 Overview
CVE-2024-5225 is a SQL Injection vulnerability [CWE-89] in the berriai/litellm repository. The flaw resides in the /global/spend/logs endpoint, which builds an SQL statement by concatenating an unvalidated api_key parameter directly into the query string. Attackers with authenticated access can supply malicious input through api_key and manipulate the resulting SQL. Successful exploitation leads to unauthorized data access, data manipulation, disclosure of sensitive information, and denial of service. The issue affects the latest version of the repository at the time of publication.
Critical Impact
Attackers authenticated to LiteLLM can inject arbitrary SQL through the api_key parameter, exposing spend logs and backend database contents.
Affected Products
- berriai/litellm (latest version at time of disclosure)
- LiteLLM deployments exposing the /global/spend/logs endpoint
- Any downstream service embedding the vulnerable LiteLLM proxy
Discovery Timeline
- 2024-06-06 - CVE-2024-5225 published to the National Vulnerability Database
- 2026-06-17 - Last updated in NVD database
Technical Details for CVE-2024-5225
Vulnerability Analysis
The /global/spend/logs endpoint in LiteLLM accepts an api_key query parameter and uses it to retrieve spend logs from the backend database. The handler concatenates the parameter into a raw SQL statement instead of binding it as a parameterized value. Any request-controlled string therefore becomes part of the query syntax.
An authenticated attacker can inject SQL clauses such as UNION SELECT, boolean-based blind conditions, or stacked statements. This allows extraction of tables outside the spend log scope, modification of stored rows, or triggering resource-intensive queries that stall the database. Because LiteLLM typically stores API keys, user records, and usage telemetry in the same database, the blast radius extends across the entire proxy deployment.
Root Cause
The root cause is improper neutralization of special elements used in an SQL command [CWE-89]. The api_key parameter is trusted as a literal string and inserted into a query without prepared statements, an ORM binding, or input validation. There is no allow-list on api_key format, so characters such as ', ;, and -- reach the database driver intact.
Attack Vector
Exploitation requires network access to the LiteLLM proxy and authenticated privileges sufficient to reach the /global/spend/logs endpoint. The attacker crafts a request in which api_key carries a SQL payload rather than a legitimate key value. The malicious payload alters the executed query and returns attacker-selected data or performs write operations. See the Huntr Bounty Overview for the disclosed technical details.
Detection Methods for CVE-2024-5225
Indicators of Compromise
- HTTP requests to /global/spend/logs containing SQL metacharacters in the api_key parameter such as ', ", ;, --, /*, or UNION.
- Database logs showing unexpected UNION SELECT, INFORMATION_SCHEMA, or pg_catalog queries originating from the LiteLLM service account.
- Elevated response times or 500 errors on /global/spend/logs correlated with unusual query patterns.
Detection Strategies
- Enable query logging on the backend database and alert on statements referencing spend tables together with system catalog objects.
- Deploy a Web Application Firewall rule that inspects api_key values for SQL syntax and rejects non-conforming inputs.
- Baseline normal /global/spend/logs traffic per user and flag deviations in parameter length, entropy, and response size.
Monitoring Recommendations
- Forward LiteLLM proxy access logs and database audit logs to a centralized analytics platform for correlation.
- Monitor authentication events for reused or leaked api_key values that could be repurposed for injection attempts.
- Track outbound traffic from the LiteLLM host for signs of exfiltration following anomalous database reads.
How to Mitigate CVE-2024-5225
Immediate Actions Required
- Upgrade LiteLLM to a release that patches the /global/spend/logs SQL injection issue referenced in the Huntr Bounty Overview.
- Restrict network exposure of the LiteLLM admin and spend endpoints to trusted management networks only.
- Rotate any API keys, database credentials, and secrets stored in the LiteLLM database if exploitation is suspected.
Patch Information
Update to the latest fixed version of berriai/litellm published after the disclosure referenced in the Huntr advisory. Review the project changelog to confirm the /global/spend/logs handler uses parameterized queries or an ORM binding before returning to production.
Workarounds
- Block or filter requests to /global/spend/logs at a reverse proxy until the upgrade is applied.
- Enforce strict input validation on the api_key parameter, allowing only expected key formats such as alphanumeric prefixes.
- Run the LiteLLM database user with least-privilege permissions so that injected queries cannot reach unrelated schemas.
# Example NGINX rule to block SQL metacharacters in api_key
location /global/spend/logs {
if ($arg_api_key ~* "('|\"|;|--|/\*|union|select|insert|update|delete)") {
return 403;
}
proxy_pass http://litellm_upstream;
}
Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.

