LiteLLM CVE-2026-42208: AI Gateway SQL Injection Added to CISA KEV

LiteLLM has become, in just a few months, the reference AI Gateway — used by thousands of organizations to proxy calls to OpenAI, Anthropic, Bedrock, Vertex AI, with centralized key management, rate limiting, observability, and internal chargeback. On May 8, 2026, the maintainer disclosed CVE-2026-42208, a critical SQL injection (CVSS 9.8) that lets an unauthenticated attacker read — and potentially modify — the proxy's database, including the API keys it manages. The vulnerability was added to the CISA KEV catalog the same day.

If you run a production LiteLLM instance, patching is urgent: your LLM API keys (often worth thousands of dollars in credit) and your user credentials are exposed.

Technical Details

Vulnerable component

When a client hits a LiteLLM LLM route (e.g. POST /chat/completions), the proxy validates the key supplied in the Authorization header. This check runs a SQL query against the proxy's internal database.

In vulnerable versions, the caller-supplied key value is mixed into the SQL query text instead of being passed as a separate parameter (classic SQL parameterization). Concretely, the code builds something like:

# Reconstructed pseudo-code — vulnerable pattern
query = f"SELECT * FROM keys WHERE token = '{auth_header}'"
db.execute(query)

An attacker can therefore send a crafted Authorization header that injects arbitrary SQL into the query. The vulnerability is reached through the proxy's error-handling path, which means it's exploitable without a valid API key.

Characteristics

Affected Products and Versions

Check your version:

# Docker
docker inspect <litellm-container> --format '{{.Config.Image}}'

# Pip / Python
pip show litellm | grep Version

# Helm
helm list -A | grep litellm

Exploitation and Impact

Exploitation conditions

Any LiteLLM instance reachable over HTTP/HTTPS — typically internal on Kubernetes, but a non-trivial number of instances are exposed via Ingress or directly on the internet (multi-tenant SaaS deployments).

Generic PoC

# Example malicious Authorization header
curl -X POST "https://litellm.example.com/chat/completions" \
  -H "Authorization: Bearer ' UNION SELECT api_key,2,3,4 FROM keys-- " \
  -H "Content-Type: application/json" \
  -d '{"model":"gpt-4","messages":[]}'

The proxy's error response may leak data extracted from the database.

Impact

1. Mass theft of LLM API keys

LiteLLM stores in its database every API key it proxies: OpenAI, Anthropic, Bedrock, Vertex AI, Azure OpenAI. An attacker who exfiltrates them can:

• Burn thousands of dollars in credit within hours (OpenAI keys typically authorize several thousand dollars in tokens per day)
• Use the keys for illicit workloads: mass content generation for scam, disinformation, fraud
• Persist by re-collecting keys regularly (provider-side key rotation: 24-72h minimum)

2. Virtual LiteLLM key theft

LiteLLM mints virtual keys issued to each internal user. Stealing them lets the attacker impersonate any user in the system.

3. Configuration tampering

If LiteLLM's SQL account has write permissions (common), the attacker can:

• Create admin accounts
• Disable quota / rate limits
• Modify routing to intercept traffic

4. Conversation history theft

LiteLLM stores LLM requests/responses (depending on configuration). Potentially sensitive data: prompts containing business data, proprietary code, customer records, etc.

Detection and IOCs

LiteLLM logs

Enable verbose logging and hunt Authorization headers with SQL injection patterns:

# Typical attempt log
grep -E "Authorization.*['\"].*(UNION|SELECT|INSERT|UPDATE|DROP|--|;)" /var/log/litellm/access.log

Indicators:

• Authorization headers containing single quotes, UNION, SELECT, --
• Abnormal volume of 500 responses on LLM routes (malformed SQLi payloads crash the parser)
• Response bodies abnormally large (data extraction)

Database logs

On the Postgres / MySQL hosting LiteLLM:

-- Postgres: log slow / suspicious queries
SET log_statement = 'mod';
SET log_min_duration_statement = 100;

Look for:

• SELECT queries on keys or user_api_keys with unusual UNION clauses
• Access to sensitive tables from the LiteLLM SQL user

Indicators of compromise

• Abnormal spike in billing at OpenAI/Anthropic/Bedrock in the week following CVE disclosure (>3 days unpatched = strong suspicion)
• Unsolicited virtual key creation
• Access from unknown external IPs on admin routes

Mitigation and Patch

Immediate action: patch to 1.83.7

# Docker
docker pull ghcr.io/berriai/litellm:v1.83.7
docker compose up -d

# Pip
pip install --upgrade litellm==1.83.7

# Helm
helm upgrade litellm berriai/litellm --version <matching-chart-version>

Incident response procedure (run even if you patched immediately)

If your instance was internet-exposed during the vulnerability window (any version 1.81.16 → 1.83.6 between late April 2026 and your patch date):

1. Rotate every LLM API key stored in LiteLLM (provider-side: OpenAI, Anthropic, Bedrock, etc.)
2. Revoke every LiteLLM virtual key and issue new ones
3. Audit billing logs at OpenAI/Anthropic for the last 30 days for unusual usage
4. Verify the users table integrity (unsolicited admin account creation)
5. Rotate the database credentials used by LiteLLM

Long-term hardening

• Restrict SQL permissions of LiteLLM's DB account (read/write on required tables only, no CREATE, no GRANT)
• Put a WAF in front (Cloudflare, AWS WAF, ModSecurity) with active SQL injection ruleset on /chat/completions, /embeddings, etc.
• Restrict network access to the LiteLLM instance: VPN, mTLS, IP allowlist
• Enable audit logging and forward to a SIEM
• Rotate LLM API keys regularly even outside incidents (every 90 days)

Why Continuous Monitoring of AI Tools Matters

The AI/LLM ecosystem moves at breakneck speed: LiteLLM isn't part of the tools traditionally scanned by vulnerability inventories, yet it handles high-value API keys (thousands of dollars in daily credit) and potentially sensitive data. A CVE like this one, added to CISA KEV within 24h, can cost dearly if it stays unpatched for a few days.

With cveo.tech, inventory your AI infrastructure tools (LiteLLM, LangChain proxies, vLLM, OpenLLM…) alongside your classic apps and get automatic alerts the moment a critical CVE targets one of your exact versions — so you patch before your API keys end up resold on the dark web.