LiteLLM CVE-2026-42208: a pre-auth SQL injection in the AI gateway

What is CVE-2026-42208?

CVE-2026-42208 (GHSA-r75f-5x8p-qvmc, CVSS 9.3) is a pre-authentication SQL injection in LiteLLM, the open-source OpenAI-compatible proxy with more than 22,000 GitHub stars that fronts OpenAI, Anthropic, Bedrock and dozens of other model providers. The maintainer-side advisory was published on April 20, 2026, the patch shipped in v1.83.7 on April 19, and the entry was mirrored in the global GitHub Advisory Database on April 24, 2026. The Sysdig Threat Research Team observed the first targeted exploitation attempt 36 hours and seven minutes later, on April 26 at 04:24 UTC. CISA added it to the Known Exploited Vulnerabilities catalog on May 8, 2026.

How it works

In affected versions (v1.81.16 through v1.83.6), the proxy’s API-key verification path concatenates the value of the Authorization: Bearer header directly into a SELECT against the LiteLLM_VerificationToken table, without parameter binding. The check runs before authentication is decided, so anything that can reach the proxy port can drive arbitrary SQL.

The shape Sysdig recorded in the wild is straightforward:

POST /chat/completions HTTP/1.1
Authorization: Bearer sk-litellm' UNION SELECT api_key,NULL,NULL,NULL,NULL FROM "LiteLLM_VerificationToken"--
User-Agent: Python/3.12 aiohttp/3.9.1

The sk-litellm' prefix is not a real key — the trailing single quote closes the SQL literal so the UNION payload runs against the leaked column. Two operator details matter for defenders. First, the attacker already knew the Prisma-generated PascalCase identifier ("LiteLLM_VerificationToken"), which suggests they read LiteLLM’s open-source schema before firing. Second, the very first salvos targeted the three highest-value tables on the proxy: LiteLLM_VerificationToken (virtual keys and the master key), litellm_credentials.credential_values (raw upstream provider credentials), and litellm_config.config_value WHERE param_name='environment_variables' (the proxy’s runtime env, typically including the PostgreSQL DSN and webhook URLs).

The fix is one line: replace the string interpolation with a parameterised query. It landed in v1.83.7 and the maintainers now recommend v1.83.10-stable.

Why it matters

A SQL injection against a generic web app leaks rows. A SQL injection against an AI gateway leaks the keys to every model account it brokers. A single litellm_credentials row routinely holds a production OpenAI organisation key with a five-figure monthly spend cap, an Anthropic console key with workspace-admin rights, and an AWS Bedrock IAM credential. Once stolen, those keys can be replayed against /chat/completions from any IP — LiteLLM does not bind keys to a source by default. The blast radius is closer to a cloud-account compromise than a typical web-app SQLi.

Three broader patterns deserve attention, all consistent with the LMDeploy SSRF (CVE-2026-33626) and the wider 2026 wave of AI-infrastructure CVEs:

• AI gateways are tier-1 credential surfaces. They aggregate provider secrets that previously sat behind separate boundaries.
• Exploit windows are collapsing. 36 hours from advisory to schema-aware exploitation, with no public PoC required. Defender pipelines keyed on CISA KEV would not have surfaced this in time.
• Schema knowledge precedes payload. Open-source ORMs publish the table names attackers need. The cost of reconnaissance approaches zero.

Defenses

Concrete steps, in order of urgency:

• Upgrade now to v1.83.10-stable (or any release >= v1.83.7). If patching is blocked, place the proxy behind a reverse proxy that rejects any Authorization header containing single quotes, parentheses or the tokens UNION, SELECT, FROM, --.
• Treat the database as compromised for any internet-reachable instance that ran an affected version. Rotate every virtual key, the master key, and every stored provider credential. Audit the upstream billing portals for /chat/completions traffic from unfamiliar source IPs.
• Get the proxy off the public internet. AI gateways consolidate enough credential value that direct internet exposure is no longer a defensible default — front them with mTLS or a corporate identity-aware proxy.
• Bind keys to a source. Where the platform supports it, scope virtual keys to expected client IPs or service identities so an exfiltrated key is not interchangeable with the legitimate caller’s.
• Monitor for the request signature. A single Authorization: Bearer sk-litellm' request is a high-confidence indicator. Sysdig’s IOCs cover both source IPs 65.111.27.132 and 65.111.25.67 (AS200373).
• Inventory the gateway surface. Application teams routinely stand up LiteLLM, OpenLLM and similar tools outside standard security review. Find them before someone else does.

Status

Item	Date	Status
Patch released (v1.83.7)	Apr 19, 2026	Public
Maintainer advisory (GHSA)	Apr 20, 2026	Public
Global GHSA database index	Apr 24, 2026	Public
First exploitation attempt observed	Apr 26, 2026	Public (Sysdig)
LiteLLM blog post	Apr 29, 2026	Public
Added to CISA KEV	May 8, 2026	Public
Recommended version	v1.83.10-stable	Current

The takeaway is uncomfortable but actionable: in May 2026, an LLM gateway exposed to the public internet on a vulnerable version should be considered compromised, not merely vulnerable.