CVE-2026-42208

Overview

CVE-2026-42208 is a pre-authentication SQL injection vulnerability in BerriAI LiteLLM, a widely deployed open-source LLM API gateway. An unauthenticated remote attacker can inject arbitrary SQL via the Authorization: Bearer header, directly targeting the authentication path — the query that verifies API keys. Successful exploitation gives full read/write access to the proxy database, which in production environments typically contains upstream provider credentials for OpenAI, Anthropic, AWS Bedrock, and other AI services.

Exploitation was observed in the wild within 36 hours of the advisory being publicly indexed, using scripted UNION-based payloads to extract credential tables.

What is LiteLLM?

LiteLLM is an open-source LLM gateway/proxy (45,000+ GitHub stars) that routes API calls to OpenAI, Anthropic, Azure OpenAI, AWS Bedrock, Google Vertex AI, and dozens of other model providers through a single unified endpoint. Enterprise teams deploy it to centralize API key management, enforce budget caps, log usage, and expose a single POST /v1/chat/completions surface to internal consumers.

Why it's a high-value target: The database managed by a LiteLLM proxy is uniquely dangerous to compromise. A single litellm_credentials table row typically holds an OpenAI organization key, an Anthropic console key with workspace admin rights, and AWS Bedrock IAM credentials — all in one place. In default Docker deployments the application database user is a PostgreSQL superuser, giving the attacker full read/write access to every table. As Sysdig characterized it: the blast radius is "closer to a cloud-account compromise than a typical web-app SQL injection."

Affected Versions

Package: litellm (PyPI / pip)

Technical Details

Root Cause

The injection point is in litellm/proxy/utils.py, within PrismaClient.get_data(). The Authorization: Bearer <value> header is passed as {token} directly into a Python f-string that constructs a raw SQL query against the LiteLLM_VerificationToken table, with no sanitization or parameterization:

sql_query = f"""
   SELECT v.*, t.spend AS team_spend, t.max_budget AS team_max_budget, ...
   FROM "LiteLLM_VerificationToken" AS v
   ...
   WHERE v.token = '{token}'
"""

A single quote in the bearer value escapes the string literal, allowing arbitrary SQL to be appended. Because this query is in the authentication path itself, it fires on every request to every proxied LLM route — no credentials required.

Two Exploitation Paths

Path A — optimized Python deployments: When LiteLLM runs with -O / PYTHONOPTIMIZE=1 (a common Docker optimization), Python strips all assert statements at runtime. The defensive guard that rejects tokens not prefixed with sk- is an assert — it disappears entirely, sending the raw bearer directly to the query.

Path B — standard deployments: Without the optimization flag, if the token does not start with sk-, the assertion fires and is caught by an exception handler that calls _enrich_failure_metadata_with_key_info(). This error-handling path also passes the unsanitized bearer into a SQL query.

Both paths reach vulnerable SQL construction; Path A is slightly more direct.

Attack Characteristics

Detection payload (time-based blind):

Authorization: Bearer ' OR (SELECT pg_sleep(6)) IS NULL --

Vulnerable hosts respond in ~6 seconds; patched hosts respond in under 100ms.

Extraction payload example:

Authorization: Bearer sk-litellm' UNION SELECT api_key,NULL,NULL,NULL,NULL FROM litellm_verificationtoken--

Discovery

Reported by Tencent YunDing Security Lab through BerriAI's bug bounty program. The GitHub advisory GHSA-r75f-5x8p-qvmc was published April 19, 2026, with a patched release available simultaneously.

Exploitation Context

Active exploitation was first observed by Sysdig on April 26, 2026 at approximately 04:24 UTC — roughly 36 hours after the advisory was indexed in the public GitHub Advisory Database on April 24. This gap reflects the time for automated vulnerability scanners to index the advisory and threat actors to weaponize the PoC.

Observed attack session (Sysdig analysis):

Tables targeted (in order):

1. LiteLLM_VerificationToken / litellm_verificationtoken — virtual API keys as SHA-256 hashes, master keys, team bindings, budget caps
2. litellm_credentials.credential_values — upstream provider credentials (OpenAI, Anthropic, AWS Bedrock IAM)
3. litellm_config — proxy environment variables, PostgreSQL DSN, webhook URLs

Threat actor infrastructure:

• Source IPs: 65.111.27.132 and 65.111.25.67 (ASN AS200373 — 3xK Tech GmbH, Germany; VPS/proxy infrastructure)
• User-Agent: Python/3.12 aiohttp/3.9.1 — fully scripted, not manual browsing
• No confirmed post-exploitation activity (no authenticated follow-on, no key reuse observed in the analysis window)

Remediation

1. Upgrade to litellm >= 1.83.7 — the vendor recommends 1.83.10-stable as the stable target. Run pip install --upgrade litellm or update your Docker image tag.

2. Interim workaround (if immediate upgrade is not possible): add disable_error_logs: true under general_settings in config.yaml. This blocks the error-handling code path (Path B) that reaches the vulnerable query. Note: this only mitigates Path B; instances running with -O / PYTHONOPTIMIZE=1 remain vulnerable via Path A.

3. Deploy a WAF rule rejecting Authorization bearer values that do not match ^sk-[A-Za-z0-9_-]+$. This blocks all known exploitation payloads with minimal false positives.

4. Rotate all credentials — if your instance was running a vulnerable version (1.81.16–1.83.6) and was internet-accessible, assume all virtual keys and upstream provider credentials stored in the database were compromised. Rotate OpenAI, Anthropic, AWS Bedrock, and any other configured provider keys immediately.

5. Review PostgreSQL query logs for exploitation attempts — look for UNION keywords, pg_sleep, or unusually long bearer values in queries against litellm_verificationtoken. The vendor provides a helper query in the official advisory.

6. Restrict database permissions — in production, the LiteLLM app user should not be a PostgreSQL superuser. Scope it to only the tables it requires.

7. Network isolation — LiteLLM proxy endpoints should not be directly internet-facing without an authenticating reverse proxy or API gateway in front.