How a single quote in an API request let attackers drain every AI provider credential from a company's gateway

The Context

LiteLLM is an open-source proxy server that sits between an organization's applications and the AI providers those applications call. Instead of every app holding its own OpenAI key or Anthropic key, a company routes all AI traffic through LiteLLM, which manages authentication, rate limiting, cost tracking, and provider switching in one place. The project has over 45,000 GitHub stars and 7,600 forks, and it is used by enterprise AI teams, startups, and individual developers. Its appeal is exactly what made this vulnerability severe: it centralizes credentials by design.

The Attack, Phase by Phase

Phase 1: The Vulnerable Gate

LiteLLM's proxy must check every incoming request against its database before deciding whether to forward it to an AI provider. In affected versions (v1.81.16 through v1.83.6), that check worked by taking the raw value from the Authorization: Bearer header and dropping it directly into a SQL query string. The query ran against the LiteLLM_VerificationToken table to look up whether the token was valid.

The problem: the query ran before any authentication decision was made. An attacker who could reach the proxy on port 4000 could send any value in the Bearer header, and the database would process it. Appending a single-quote character (') to a fake token like sk-litellm' broke out of the SQL string literal, allowing arbitrary SQL to follow. The vulnerability was also reachable through the proxy's error-handling path, meaning even a malformed token triggered the vulnerable code rather than being rejected early.

Phase 2: Schema Reconnaissance and First Probe

The attacker did not arrive blind. Before sending the first request, they had read LiteLLM's public Prisma ORM schema on GitHub, which documents the exact table names and column structures of the database. This preparation mattered: LiteLLM uses PascalCase for some table names (LiteLLM_VerificationToken) and lowercase for others (litellm_credentials), a detail that is not guessable.

Starting at 04:24 UTC on April 26, 2026, from IP 65.111.27.132, the attacker sent POST /chat/completions requests with UNION SELECT payloads using lowercase table names and varying column counts. These returned errors, which confirmed the database structure and allowed the attacker to calibrate the correct column count for a successful union.

Phase 3: Precision Extraction with IP Rotation

Approximately 20 minutes after Phase 2, the attacker switched to a second IP address (65.111.25.67) in an adjacent network block registered to the same provider. Armed with the corrected table names and column counts from Phase 2, they issued refined payloads targeting three specific tables.

LiteLLM_VerificationToken holds virtual API keys and the master key. litellm_credentials stores upstream provider credentials: OpenAI organization keys, Anthropic console keys, AWS Bedrock IAM credentials. litellm_config holds proxy environment variables that can include database connection strings, cache credentials, and callback endpoints. All three are reachable from a single UNION SELECT chain. The attacker did not probe lower-value tables like litellm_users or litellm_team, confirming they went directly for the credential-bearing tables.

Phase 4: Key-Management Endpoint Probe

After the SQL injection phases, the operator conducted a brief unauthenticated probe of LiteLLM's key-management endpoints. Because LiteLLM does not bind virtual keys to a source IP address by default, any key successfully extracted from the database could be immediately replayed against /chat/completions from any location, granting full authenticated access to every connected AI provider account.

What Made This Possible

1. The authentication check was the injection point. The code that was supposed to reject unauthorized callers was itself built on unsanitized input. The security boundary and the vulnerability were the same line of code.

2. Credential centralization amplified the blast radius. LiteLLM's value proposition is that it holds all your AI provider credentials in one place. That design choice, without corresponding security controls, turned a single database read into a full account takeover across every connected provider.

3. The public schema eliminated the reconnaissance barrier. LiteLLM's Prisma ORM schema is publicly documented on GitHub. The attacker used it to craft precise payloads before sending a single request, compressing the time from disclosure to working exploit to under 36 hours.

The advisory was not added to CISA's Known Exploited Vulnerabilities (KEV) catalog, meaning organizations relying on KEV-based alerting had no automated signal that active exploitation had begun.

What Should Have Stopped This

No single defense here depends on the proxy's own authentication integrity being intact. That is the unifying principle: controls that sit outside the vulnerable component remain effective even when the component's internal security fails.

• Network isolation. LiteLLM proxy instances should not be reachable from untrusted networks. Placing the proxy behind a private network boundary or VPN means an attacker who finds the vulnerability cannot reach the vulnerable port.
• Credential scoping at the provider level. OpenAI, Anthropic, and AWS all support restricting API keys to specific IP ranges, usage caps, or permission scopes. A key that can only be used from a known IP range cannot be replayed from an attacker's server even if it is extracted.
• Dependency alerting on GitHub Security Advisories. The patch was available in v1.83.7 on April 19, five days before exploitation began. Tools like Dependabot alert on new GitHub Security Advisories automatically. Organizations with that alerting enabled had a five-day window to patch before the first attack.
• Postgres query log review. LiteLLM's vendor advisory includes a helper query for reviewing Postgres query history. For organizations that were exposed, this is the primary forensic tool to determine whether extraction occurred.

The Takeaway

AI gateways have become a new tier-1 credential surface. They are designed to centralize the most valuable secrets in an AI-enabled organization, but they are frequently deployed by application teams who treat them as developer conveniences rather than secrets managers. The security review that would apply to a production secrets vault does not always follow.

This is the same class of failure as the Stryker Intune wipe: a tool built to manage privileged access was itself the attack surface. In the Stryker case, the management tool was weaponized after credential compromise. Here, the management tool was weaponized before authentication even completed. The meta-pattern: systems fail when the mechanism designed to enforce a security boundary is built on the same untrusted input it is supposed to evaluate.

Pattern to remember: When the security check itself processes untrusted input before validating it, the check and the vulnerability are the same code path.

What changed: Pre-authentication SQL injection in a credential-centralizing gateway collapses the distinction between "unauthenticated caller" and "authenticated admin," because the injection executes inside the function that would have drawn that line.

The Technical Mechanism

CVE-2026-42208 is a pre-authentication SQL injection vulnerability in the LiteLLM proxy server's API key verification path. The root cause is string interpolation of a caller-supplied value into a SQL SELECT query against the LiteLLM_VerificationToken table in PostgreSQL.

In affected versions (>=1.81.16, <1.83.7), the proxy's key verification function extracted the raw Bearer token string from the Authorization header and concatenated it directly into query text, equivalent to:

SELECT * FROM "LiteLLM_VerificationToken" WHERE token = '<caller_value>'

A caller-supplied value containing a single-quote character (') terminates the SQL string literal, allowing arbitrary SQL to follow. The vulnerability is classified under CWE-89 (Improper Neutralization of Special Elements used in an SQL Command). The attack vector is Network, attack complexity is Low, no privileges are required, and no user interaction is required. CVSS score: 9.3 (Critical).

The injection is additionally reachable through the proxy's error-handling code path, meaning malformed or nonsensical token values route through the vulnerable branch rather than being rejected before reaching the database layer. This expands the attack surface beyond the nominal authentication flow.

The observed exploitation used UNION SELECT payloads to enumerate and extract rows from three tables:

• LiteLLM_VerificationToken: virtual API keys and the master key
• litellm_credentials: upstream provider credentials (OpenAI, Anthropic, AWS Bedrock IAM)
• litellm_config: proxy environment variables including database DSNs, cache credentials, and callback endpoints

Tautological payloads (OR 1=1--) were also observed. All requests used User-Agent: Python/3.12 aiohttp/3.9.1 and targeted POST /chat/completions and POST /v1/chat/completions exclusively.

The fix in v1.83.7 replaces string interpolation with a parameterized query, passing the caller-supplied value as a separate bound parameter that the database driver treats as data, not as query structure.

runZero's advisory documents that CVE-2026-42208 can be chained with a second advisory (GHSA-xqmj-j6mv-4862) to achieve remote code execution on the proxy host. Official LiteLLM container images run the proxy process as root, amplifying the impact of any RCE chain. A concurrent authenticated vulnerability (CVE-2026-42271) affecting MCP stdio test endpoints enables command execution by low-privileged attackers.

CVE and Advisories

• CVE-2026-42208: Pre-authentication SQL injection in LiteLLM proxy API key verification. CVSS 9.3 Critical. Affects litellm (pip) >=1.81.16, <1.83.7. Fixed in v1.83.7.
• GHSA-r75f-5x8p-qvmc: GitHub Security Advisory published April 20, 2026; indexed in the global advisory database April 24, 2026.
• CVE-2026-42271: Concurrent authenticated RCE vulnerability in LiteLLM MCP stdio test endpoints. Disclosed concurrently.
• CCB Advisory, April 29, 2026: Centre for Cybersecurity Belgium public warning urging immediate patching.
• LiteLLM Vendor Blog, April 20, 2026: Official vendor advisory with patching guidance and Postgres forensic helper query.

Not listed in CISA KEV catalog at time of writing.

MITRE ATT&CK Mapping

Indicators of Compromise

Network Indicators

• Source IP 65.111.27.132 (Phase 1, 3xK Tech GmbH, Germany)
• Source IP 65.111.25.67 (Phase 2, same autonomous system, adjacent /22 block)
• Both IPs assessed as likely egress proxies or rented VPS endpoints, not the operator's true origin

Request Pattern Indicators

• POST /chat/completions or POST /v1/chat/completions with Authorization: Bearer values containing single-quote characters (')
• UNION SELECT strings in Bearer header values
• OR 1=1-- strings in Bearer header values
• User-Agent: Python/3.12 aiohttp/3.9.1 on requests with malformed Bearer tokens
• Requests targeting LiteLLM_VerificationToken, litellm_credentials, or litellm_config in payload strings

Detection Limitations

The advisory was not added to CISA's KEV catalog, meaning CVE-keyed or KEV-based alerting did not surface active exploitation automatically. Organizations should review PostgreSQL query logs using the forensic helper query published in the LiteLLM vendor advisory. Sysdig confirmed no successful authenticated follow-on in the monitored window, but noted this does not rule out successful extraction by the observed operator or other unmonitored actors.

Attribution

Unattributed. The observed exploitation originated from two IPs (65.111.27.132 and 65.111.25.67) registered to 3xK Tech GmbH in Germany. Sysdig assessed with moderate confidence that both represent a single operator rotating egress, based on identical Python/3.12 aiohttp/3.9.1 user-agents and the sequential, schema-aware nature of the two-phase attack. The IPs may be proxies or rented VPS endpoints. No attribution to a known advanced persistent threat group or nation-state has been established. The methodology did not match commodity botnet patterns; the schema pre-reading and targeted table selection indicate a threat actor with significant expertise in SQL injection and cloud infrastructure targeting. The original vulnerability was reported to LiteLLM through its bug bounty program by an unnamed researcher.

Primary Sources