CVE-2026-42208: LiteLLM Proxy Server SQL Injection Flaw

CVE-2026-42208 Overview

CVE-2026-42208 is a SQL injection vulnerability [CWE-89] in LiteLLM, an AI Gateway proxy server used to call large language model (LLM) APIs in OpenAI-compatible format. The flaw exists in the database query that validates proxy API keys. The query concatenates the caller-supplied key value into the SQL text instead of binding it as a parameter. An unauthenticated attacker can send a crafted Authorization header to any LLM API route, such as POST /chat/completions, and reach the vulnerable query through the proxy's error-handling path. The issue affects versions from 1.81.16 to versions before 1.83.7.

Critical Impact

An unauthenticated remote attacker can read and potentially modify data in the LiteLLM proxy database, exposing managed LLM provider credentials and proxy API keys.

Affected Products

• LiteLLM versions 1.81.16 through 1.83.6
• BerriAI LiteLLM proxy server deployments serving as an AI Gateway
• Self-hosted LiteLLM instances exposing LLM API routes such as /chat/completions

Discovery Timeline

• 2026-05-08 - CVE-2026-42208 published to NVD
• 2026-05-08 - Last updated in NVD database
• Patch released - Fixed in LiteLLM version 1.83.7 via GitHub Release v1.83.7
• Listed in - CISA Known Exploited Vulnerabilities Catalog

Technical Details for CVE-2026-42208

Vulnerability Analysis

LiteLLM acts as a proxy gateway that authenticates clients using API keys passed in the HTTP Authorization header. During request handling, the proxy looks up the supplied key in its backing database to determine validity and associated permissions. The lookup logic builds the SQL statement by interpolating the raw key value into the query string rather than using a parameterized statement. This pattern is the classic root cause of SQL injection [CWE-89].

Because the vulnerable query is reached through the proxy's error-handling path, attackers do not need a valid API key to trigger it. Any LLM API route that performs key validation, including POST /chat/completions, can serve as an injection sink. The result is an unauthenticated SQL injection against the LiteLLM database.

The vulnerability carries high impact across confidentiality and integrity. The proxy database typically stores hashed API keys, virtual key metadata, user records, budgets, and provider credentials used to reach upstream LLM services such as OpenAI, Anthropic, or Azure OpenAI. Exfiltration of these secrets enables onward abuse of paid LLM accounts and lateral access into AI workloads.

Root Cause

The proxy API key validation logic concatenates the attacker-controlled Authorization header value directly into a SQL query string. Parameter binding is bypassed, so SQL metacharacters in the key are interpreted as query syntax rather than data.

Attack Vector

The attack vector is the network. An attacker issues an HTTP request to any LLM API route exposed by the LiteLLM proxy and places a SQL injection payload inside the Authorization: Bearer <payload> header. The proxy's error-handling path forwards the malicious value into the unsafe query, executing attacker-controlled SQL against the backend database. See the GitHub Security Advisory GHSA-r75f-5x8p-qvmc for vendor analysis.

Detection Methods for CVE-2026-42208

Indicators of Compromise

• Inbound HTTP requests to LiteLLM routes such as /chat/completions, /completions, or /embeddings containing SQL metacharacters (', --, ;, UNION, SELECT) inside the Authorization header.
• LiteLLM application logs showing repeated authentication errors or database exceptions tied to malformed bearer tokens.
• Unexpected database queries originating from the LiteLLM service account, especially queries referencing information_schema, pg_catalog, or key/credential tables.
• Outbound traffic spikes from the LiteLLM host to attacker-controlled infrastructure following anomalous header activity.

Detection Strategies

• Inspect reverse proxy and WAF logs for non-printable or SQL-syntax characters in Authorization headers reaching LiteLLM endpoints.
• Correlate LiteLLM error logs containing database driver exceptions with the source IPs of requests that produced them.
• Hunt for newly created or unexpectedly modified rows in LiteLLM's keys, users, and provider credential tables.

Monitoring Recommendations

• Enable verbose request logging on the LiteLLM proxy and forward logs to a centralized analytics platform for retention and search.
• Alert on a high ratio of 4xx authentication failures combined with database error stack traces from the LiteLLM process.
• Monitor LLM provider billing dashboards for sudden cost spikes that may indicate stolen upstream credentials in use.

How to Mitigate CVE-2026-42208

Immediate Actions Required

• Upgrade LiteLLM to version 1.83.7 or later using the GitHub Release v1.83.7 artifacts.
• Rotate all LiteLLM proxy API keys, virtual keys, and upstream LLM provider credentials stored by the proxy, assuming compromise if exposure cannot be ruled out.
• Review the LiteLLM database for unauthorized rows, modified permissions, or new administrative users created since version 1.81.16 was deployed.
• Restrict network exposure of the LiteLLM proxy to trusted clients via firewall rules, private networking, or an authenticated reverse proxy.

Patch Information

The vulnerability is patched in LiteLLM 1.83.7. The fix changes the proxy API key lookup to bind the supplied key as a query parameter rather than concatenating it into SQL. All deployments running versions 1.81.16 through 1.83.6 must upgrade. Patch and advisory details are documented in the GitHub Security Advisory GHSA-r75f-5x8p-qvmc.

Workarounds

• Place a web application firewall in front of LiteLLM and block requests whose Authorization header contains SQL metacharacters or non-token syntax.
• Require mutual TLS or an upstream identity-aware proxy so that only authenticated clients can reach LiteLLM API routes.
• Apply least-privilege database credentials to the LiteLLM service account, removing DDL and write rights on tables that the proxy does not need to modify.

# Configuration example: upgrade LiteLLM and rotate credentials
pip install --upgrade 'litellm==1.83.7'

# Verify installed version
python -c "import litellm; print(litellm.__version__)"

# Restart the LiteLLM proxy service after upgrade
systemctl restart litellm-proxy