VULNpocalypse
CriticalVulnerabilityPatch available

LiteLLM proxy SQL injection CVE-2026-42208: unauthenticated reads of virtual keys and provider credentials

A pre-auth SQL injection in LiteLLM proxy 1.81.16 to 1.83.6 exposes API keys and provider credentials. Exploited. Upgrade to 1.84.0 or later and rotate keys.

Published
Updated
Fixed in
LiteLLM 1.83.7 (1.84.0 or later also fixes two other exploited LiteLLM bugs)
Exploitation
Yes, attempts seen by Sysdig from 26 April 2026; in CISA KEV since 8 May 2026

Live scores

CVE-2026-42208
EPSS
0.894
very likely to be attacked soon
VEDAS
0.982
strong exploit evidence
On CISA KEV
Yes, since 2026-05-08
Detection rule
Nuclei · Suricata
EPSS (chance of attack)
100.1CVE-2026-42208 EPSS over time2026-082026-11-01
VEDAS (exploit evidence)
100.9CVE-2026-42208 VEDAS over time2026-082026-11-01

Thin horizontal line: the “likely” (EPSS 0.10) or “strong” (VEDAS 0.90) threshold. Shaded “no data” areas are periods when cve-scores did not publish.

What happened

LiteLLM is an open-source proxy, or AI gateway, that sits in front of OpenAI, Anthropic and other model APIs. It hands out its own “virtual” API keys and stores the real provider credentials in its database.

From version 1.81.16, the query that checks a caller’s API key put the key value straight into the SQL text instead of passing it as a parameter. An unauthenticated attacker can send a crafted Authorization header to any LLM route, such as POST /chat/completions, and reach that query through the proxy’s error-handling path. The attacker can read the proxy’s database and may be able to change it. BerriAI published the advisory on 20 April 2026, rated it CVSS v4 9.3, and credited Tencent YunDing Security Lab. The fix is in 1.83.7 (GitHub advisory).

Attacks followed within days. Sysdig saw the first injection attempt at 04:24 UTC on 26 April, about 36 hours after the advisory reached the GitHub Advisory Database. Over 21 minutes the attacker sent 17 UNION payloads aimed at three tables: LiteLLM_VerificationToken (virtual keys, including the master key), litellm_credentials (provider credentials) and litellm_config (the proxy’s environment variables). A second address on the same network then replayed the payloads and called /key/generate and /key/info without authentication. Sysdig saw no later use of stolen keys (Sysdig; Security Affairs).

CISA added CVE-2026-42208 to the Known Exploited Vulnerabilities catalog on 8 May 2026, with a federal due date of 11 May (CISA KEV).

Am I affected?

You are affected if any LiteLLM proxy runs a version from 1.81.16 up to and including 1.83.6. The advisory covers the proxy’s API key check. Using litellm only as a client library inside your own code is not the scenario it describes (GitHub advisory).

bash
# pip or virtualenv installs
pip show litellm | grep -i '^version'

# Docker deployments (container name varies)
docker exec <litellm-container> pip show litellm | grep -i '^version'

Then search access logs for attempts. Sysdig’s indicators (Sysdig):

  • POST /chat/completions or /v1/chat/completions with an Authorization header that starts with sk-litellm' or contains UNION SELECT, FROM litellm_verificationtoken, FROM "LiteLLM_VerificationToken", FROM litellm_credentials, FROM litellm_config WHERE param_name='environment_variables' or OR 1=1--.
  • Requests from 65.111.27.132 or 65.111.25.67 (AS200373), or with the user agent Python/3.12 aiohttp/3.9.1. Sysdig notes these may be rented servers.
  • Unauthenticated calls to /key/generate or /key/info.

If your logs do not capture the Authorization header, check a reverse proxy or WAF in front of LiteLLM, and treat any internet-exposed vulnerable instance as exposed.

What to do now

  1. Upgrade the proxy. 1.83.7 fixes CVE-2026-42208 (GitHub advisory). Go to 1.84.0 or later: CISA also lists CVE-2026-42271 (command execution through MCP test endpoints, fixed in 1.83.7) and CVE-2026-59822 (MCP authentication bypass, fixed in 1.84.0) as exploited (CVE-2026-42271; CVE-2026-59822; CISA KEV).
  2. If you cannot upgrade today, set disable_error_logs: true under general_settings. BerriAI says this “removes the path through which unauthenticated input reaches the vulnerable query” (GitHub advisory). Sysdig also suggests a reverse proxy rule that rejects Authorization values containing single quotes, parentheses or SQL keywords.
  3. Rotate secrets on any exposed instance. Sysdig advises rotating the master key, all virtual keys and all stored provider credentials, and treating the database as compromised even without proof of theft. The litellm_config environment variables can include the database connection string and webhook URLs, so rotate those too (Sysdig).
  4. Check provider billing. Look at usage on your OpenAI, Anthropic, Azure and other provider accounts for calls from unfamiliar IP addresses since 20 April. Use of the master key from an unexpected source is a strong signal.
  5. Take the proxy and its admin UI off the internet. Put LiteLLM on an internal network or behind a reverse proxy that authenticates clients first.

Why this matters

An AI gateway is a credential vault. One SQL injection here returns the keys to every model provider the organization pays for. The attacker in this case went straight for the three tables that hold secrets, not a generic scan.

Sources