CVE-2026-42208: SQL Injection in BerriAI LiteLLM Exposes AI Proxy Credentials

Background

LiteLLM is an open-source LLM proxy server that has become a critical piece of AI infrastructure for organisations running multi-model AI deployments. It acts as a unified gateway, routing requests to OpenAI, Anthropic Claude, Google Gemini, Azure OpenAI, and dozens of other model providers behind a single API endpoint. More importantly, it centralises API key management — organisations store their provider API keys in LiteLLM’s database and let LiteLLM handle authentication with upstream providers.

This architectural role makes LiteLLM a high-value target: a single compromise can expose API keys giving access to every LLM provider the organisation uses, along with spending power against those providers’ billed accounts. CVE-2026-42208 is a SQL injection vulnerability in LiteLLM’s management API that allows an authenticated attacker — or an insider threat — to extract this key material.

The CISA KEV inclusion reflects exploitation in environments where LiteLLM deployments are exposed to internal developer networks with broad authentication — a common configuration in organisations that have deployed LiteLLM as a shared internal AI gateway.

Technical Mechanism

The vulnerability exists in LiteLLM’s model management API endpoint, specifically the /model/info endpoint that supports filtering by model parameters. The endpoint accepts query parameters that are incorporated into a database query. In the affected versions, the model_name query parameter is interpolated directly into a SQLite (or PostgreSQL, depending on deployment) query without parameterisation:

# Simplified vulnerable code pattern
query = f"SELECT * FROM litellm_proxymodeltable WHERE model_name = '{model_name}'"
cursor.execute(query)

An attacker with a valid LiteLLM API key (even a read-only key generated for a developer) can inject arbitrary SQL:

GET /model/info?model_name=x' UNION SELECT api_key,litellm_budget_table.team_id,created_by FROM litellm_verificationtoken--

This returns all stored API keys from the litellm_verificationtoken table, which contains both LiteLLM internal tokens and — in many configurations — the provider API keys stored as configuration values.

Beyond reading data, the injection can be extended to write operations using stacked queries (where the database driver supports them) or time-based blind injection techniques for databases that don’t return visible error output.

Real-World Exploitation Evidence

The vulnerability was initially disclosed by a security researcher via a responsible disclosure programme, but exploitation in the wild was confirmed before the researcher’s write-up was published. CISA’s KEV entry cites evidence of exploitation in AI/ML development environments.

Observed exploitation patterns in reported incidents:

• Automated scanning tools targeting LiteLLM’s default port (4000) and /model/info endpoints
• Extraction of OpenAI and Anthropic API keys subsequently used for credential stuffing and unauthorised model inference
• Modification of model routing tables to redirect AI queries through attacker-controlled endpoints (enabling prompt interception)
• Extraction of team and user configurations to map internal organisational structure

The exploitation of stolen LLM provider API keys has immediate financial consequences: attackers use them to generate model responses at the victim’s expense, with documented cases of tens of thousands of dollars in fraudulent AI API spend within hours of key compromise.

Impact Assessment

The impact of CVE-2026-42208 is distinct from traditional SQL injection in that the exposed credential type has an unusual attack surface:

• LLM provider API key theft: Keys for OpenAI, Anthropic, Google, etc. can be immediately monetised by attackers selling API access or running fraudulent inference workloads.
• Financial damage: LLM API costs are usage-based. A single stolen key can generate thousands of dollars in fraudulent charges within minutes.
• Prompt data exposure: Many LiteLLM deployments log prompts and completions. The database may contain historical AI conversation data, including sensitive business information submitted to AI models.
• Supply-chain risk: If LiteLLM is used to power customer-facing AI features, attacker control over routing could manipulate AI responses served to end users.

Affected Versions

Remediation Steps

1. Upgrade LiteLLM: Update to version 1.34.5 or later. If running via Docker: docker pull ghcr.io/berriai/litellm:main-latest and redeploy. If installed via pip: pip install litellm[proxy] --upgrade.

2. Rotate all stored API keys immediately: Any API keys stored in LiteLLM’s database should be rotated with the upstream providers. Go to OpenAI, Anthropic, and other providers and generate new API keys, then update LiteLLM configuration. The old keys may have been extracted.

3. Restrict API access: LiteLLM’s management API should never be internet-exposed. Enforce access controls at the network layer — expose only the inference endpoint (if required) and keep the management API (/model/*, /key/*, /team/* routes) accessible only from internal management networks.

4. Enable authentication: Ensure LITELLM_MASTER_KEY is set and that all API keys have appropriate permission scopes. Do not issue admin-level keys to developer users.

5. Review audit logs: Check LiteLLM logs for unexpected calls to /model/info or any endpoint with SQL metacharacters in query parameters (', --, UNION, SELECT).

6. Check upstream provider billing: Immediately review API usage on all connected LLM provider dashboards for anomalous spend patterns.

Detection Guidance

Monitor LiteLLM access logs for:

• Requests to /model/info with model_name parameter values containing SQL syntax: single quotes, UNION, SELECT, --
• Unusual spikes in API key usage from LiteLLM’s IP address at the provider level
• Repeated queries to /key/info or /team/info endpoints from the same IP
• Error responses containing SQL error messages (which may indicate probing)

Log query for nginx/uvicorn access logs: grep "model/info" access.log | grep -E "UNION|SELECT|'|--"

Timeline