GHSA-r75f-5x8p-qvmc: LiteLLM SQLi exposes all

CISO Take

LiteLLM's proxy contains a critical unauthenticated SQL injection — any attacker can craft an Authorization header on a standard LLM API endpoint (POST /chat/completions) and extract or modify the entire credentials database without logging in. For organizations using litellm as their AI gateway to centralize access to OpenAI, Anthropic, or Azure OpenAI, this means every stored API key — potentially granting access to substantial cloud spend — is at risk from a single unauthenticated HTTP request. No public exploit has been released and it is not in CISA KEV, but the attack vector requires zero AI/ML knowledge (pure classical SQLi via HTTP header) and the proxy is typically internet-exposed by design. Patch to litellm 1.83.7 immediately; if patching must wait, set disable_error_logs: true under general_settings to close the vulnerable code path, and rotate all stored API credentials if exposure cannot be ruled out.

Sources: GitHub Advisory ATLAS OpenSSF

What is the risk?

Critical severity despite the absence of a formal CVSS score. The vulnerability is unauthenticated, network-accessible, and exploitable with no AI/ML expertise — purely classical SQL injection reachable through the error-handling path of any LLM API route. The high-value target (credential store for all managed LLM APIs) amplifies impact far beyond the proxy itself; a single compromise can expose cloud billing accounts worth thousands per month across multiple providers. The package's 19 prior CVEs and a 6.5/10 OpenSSF Scorecard signal a pattern of security debt that elevates confidence this will be exploited once a working PoC circulates.

How does the attack unfold?

Reconnaissance

Attacker identifies a publicly exposed litellm proxy endpoint via Shodan, certificate transparency logs, or API response fingerprinting from identifiable litellm error formats.

AML.T0006

Initial Access

Attacker sends a POST request to /chat/completions with a SQL injection payload embedded in the Authorization header, reaching the vulnerable error-handling code path without any authentication.

AML.T0049

Credential Exfiltration

The injected SQL query reads API keys and credentials for all connected LLM providers from the proxy database, returning them in error responses or via out-of-band SQL techniques.

AML.T0106

Impact: Full LLM API Takeover

Attacker uses exfiltrated API keys to directly access all connected LLM providers (OpenAI, Anthropic, etc.), incurring charges on victim accounts and gaining access to all prompts and completions.

AML.T0040

Reconnaissance

Attacker identifies a publicly exposed litellm proxy endpoint via Shodan, certificate transparency logs, or API response fingerprinting from identifiable litellm error formats.

AML.T0006

Initial Access

Attacker sends a POST request to /chat/completions with a SQL injection payload embedded in the Authorization header, reaching the vulnerable error-handling code path without any authentication.

AML.T0049

Credential Exfiltration

The injected SQL query reads API keys and credentials for all connected LLM providers from the proxy database, returning them in error responses or via out-of-band SQL techniques.

AML.T0106

Impact: Full LLM API Takeover

Attacker uses exfiltrated API keys to directly access all connected LLM providers (OpenAI, Anthropic, etc.), incurring charges on victim accounts and gaining access to all prompts and completions.

AML.T0040

What systems are affected?

Package	Ecosystem	Vulnerable Range	Patched
LiteLLM	pip	>= 1.81.16, < 1.83.7	`1.83.7`
51.0K OpenSSF 6.1 6 dependents Pushed 3d ago 44% patched ~38d to patch Full package profile →

Do you use LiteLLM? You're affected.

How severe is it?

CVSS 3.1

N/A

EPSS

N/A

Exploitation Status

No known exploitation

Sophistication

Trivial

What should I do?

5 steps

Patch: Upgrade to litellm >= 1.83.7 immediately — the fix ensures caller-supplied values are always passed as parameterized query arguments.
Workaround (if patching is delayed): Set disable_error_logs: true under general_settings in your litellm configuration to remove the vulnerable error-handling code path.
Credential rotation: If the proxy was internet-exposed on an unpatched version, rotate all LLM API keys stored in the litellm database as a precaution — treat exposure as confirmed.
Detection: Review proxy access logs for unusual Authorization header patterns — SQL metacharacters (' ; -- UNION SELECT %27), excessively long values, or HTTP 4xx/5xx spikes on /chat/completions and similar routes from a single source.
Network hardening: Restrict litellm proxy endpoints to authenticated internal networks or VPN where business requirements permit; an AI gateway should rarely be directly internet-accessible.

How is it classified?

Auth Bypass Data Extraction Inference API AML.T0025 - Exfiltration via Cyber Means AML.T0040 - AI Model Inference API Access AML.T0049 - Exploit Public-Facing Application AML.T0055 - Unsecured Credentials AML.T0106 - Exploitation for Credential Access

Which compliance frameworks are affected?

This CVE is relevant to:

EU AI Act

Article 15 - Accuracy, robustness and cybersecurity

ISO 42001

A.6.2.1 - Information security in AI system development A.8.4 - Protection of AI system data

NIST AI RMF

GOVERN 6.1 - Policies for AI risk management are in place MANAGE 2.4 - Residual risks and incidents are managed

OWASP LLM Top 10

LLM02:2025 - Sensitive Information Disclosure LLM03:2025 - Supply Chain

Frequently Asked Questions

What is GHSA-r75f-5x8p-qvmc?

LiteLLM's proxy contains a critical unauthenticated SQL injection — any attacker can craft an Authorization header on a standard LLM API endpoint (POST /chat/completions) and extract or modify the entire credentials database without logging in. For organizations using litellm as their AI gateway to centralize access to OpenAI, Anthropic, or Azure OpenAI, this means every stored API key — potentially granting access to substantial cloud spend — is at risk from a single unauthenticated HTTP request. No public exploit has been released and it is not in CISA KEV, but the attack vector requires zero AI/ML knowledge (pure classical SQLi via HTTP header) and the proxy is typically internet-exposed by design. Patch to litellm 1.83.7 immediately; if patching must wait, set disable_error_logs: true under general_settings to close the vulnerable code path, and rotate all stored API credentials if exposure cannot be ruled out.

Is GHSA-r75f-5x8p-qvmc actively exploited?

No confirmed active exploitation of GHSA-r75f-5x8p-qvmc has been reported, but organizations should still patch proactively.

How to fix GHSA-r75f-5x8p-qvmc?

1. Patch: Upgrade to litellm >= 1.83.7 immediately — the fix ensures caller-supplied values are always passed as parameterized query arguments. 2. Workaround (if patching is delayed): Set disable_error_logs: true under general_settings in your litellm configuration to remove the vulnerable error-handling code path. 3. Credential rotation: If the proxy was internet-exposed on an unpatched version, rotate all LLM API keys stored in the litellm database as a precaution — treat exposure as confirmed. 4. Detection: Review proxy access logs for unusual Authorization header patterns — SQL metacharacters (' ; -- UNION SELECT %27), excessively long values, or HTTP 4xx/5xx spikes on /chat/completions and similar routes from a single source. 5. Network hardening: Restrict litellm proxy endpoints to authenticated internal networks or VPN where business requirements permit; an AI gateway should rarely be directly internet-accessible.

What systems are affected by GHSA-r75f-5x8p-qvmc?

This vulnerability affects the following AI/ML architecture patterns: LLM API proxies and gateways, Multi-provider LLM routing layers, Enterprise AI platforms with centralized key management, Agent frameworks routing through litellm, LLMOps pipelines using litellm for model abstraction.

What is the CVSS score for GHSA-r75f-5x8p-qvmc?

No CVSS score has been assigned yet.

What is the AI security impact?

Affected AI Architectures

LLM API proxies and gatewaysMulti-provider LLM routing layersEnterprise AI platforms with centralized key managementAgent frameworks routing through litellmLLMOps pipelines using litellm for model abstraction

MITRE ATLAS Techniques

AML.T0025 Exfiltration via Cyber Means

AML.T0040 AI Model Inference API Access

AML.T0049 Exploit Public-Facing Application

AML.T0055 Unsecured Credentials

AML.T0106 Exploitation for Credential Access

Compliance Controls Affected

EU AI Act: Article 15

ISO 42001: A.6.2.1, A.8.4

NIST AI RMF: GOVERN 6.1, MANAGE 2.4

OWASP LLM Top 10: LLM02:2025, LLM03:2025

What are the technical details?

Original Advisory

### Impact A database query used during proxy API key checks mixed the caller-supplied key value into the query text instead of passing it as a separate parameter. An unauthenticated attacker could send a specially crafted `Authorization` header to any LLM API route (for example `POST /chat/completions`) and reach this query through the proxy's error-handling path. An attacker could read data from the proxy's database and may be able to modify it, leading to unauthorised access to the proxy and the credentials it manages. ### Patches Fixed in **`1.83.7`**. The caller-supplied value is now always passed to the database as a separate parameter. Upgrade to `1.83.7` or later. ### Workarounds If upgrading is not immediately possible, set `disable_error_logs: true` under `general_settings`. This removes the path through which unauthenticated input reaches the vulnerable query.

Exploitation Scenario

An attacker discovers an organization's litellm proxy through passive reconnaissance — Shodan scans for the default port, certificate transparency logs, or API response fingerprinting (litellm returns identifiable error formats). They craft a POST to /chat/completions with a SQL injection payload embedded in the Authorization header (e.g., Bearer ' UNION SELECT api_key,NULL,NULL FROM litellm_verificationtoken--). The request fails authentication but triggers the error-handling path, which interpolates the raw bearer value directly into a database query. Database output is reflected in the error response, leaking stored API credentials for all connected LLM providers. The attacker then uses the extracted keys directly against OpenAI or Anthropic APIs — accruing charges on the victim's accounts, accessing conversation history, and potentially pivoting to other services authenticated via the same organization's API keys.

Weaknesses (CWE)

CWE-89 Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection') Primary

CWE-89 — Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection'): The product constructs all or part of an SQL command using externally-influenced input from an upstream component, but it does not neutralize or incorrectly neutralizes special elements that could modify the intended SQL command when it is sent to a downstream component. Without sufficient removal or quoting of SQL syntax in user-controllable inputs, the generated SQL query can cause those inputs to be interpreted as SQL instead of ordinary user data.

[Architecture and Design] Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid [REF-1482]. For example, consider using persistence layers such as Hibernate or Enterprise Java Beans, which can provide significant protection against SQL injection if used properly.
[Architecture and Design] If available, use structured mechanisms that automatically enforce the separation between data and code. These mechanisms may be able to provide the relevant quoting, encoding, and validation automatically, instead of relying on the developer to provide this capability at every point where output is generated. Process SQL queries using prepared statements, parameterized queries, or stored procedures. These features should accept parameters or variables and support strong typing. Do not dynamically construct and execute query strings within these features using "exec" or similar functionality, since this may re-introduce the possibility of SQL injection. [REF-867]

Source: MITRE CWE corpus.