LiteLLM Pre-Auth SQL Injection in Proxy Key Verification - CVE-2026-42208
On April 19, 2026, the LiteLLM project shipped version 1.83.7-stable to fix CVE-2026-42208 (also tracked as GHSA-r75f-5x8p-qvmc), a pre-authentication SQL injection in the LiteLLM Proxy's API key verification path. The flaw is rated CVSS 9.3. It affects LiteLLM Proxy releases 1.81.16 through 1.83.6. This advisory covers what the bug exposes, why a gateway compromise is an agentic-endpoint problem, and how Anomity surfaces and governs the agents that route through it.
What happened
LiteLLM Proxy is a gateway that fronts many upstream model providers behind a single OpenAI-compatible API. Callers present a virtual key in the Authorization: Bearer header, and the proxy validates that key against a PostgreSQL backend before forwarding the request.
In the affected versions, a database query used during proxy key checks concatenated the caller-supplied key value directly into the query text instead of binding it as a parameter. An unauthenticated attacker could send a crafted Authorization: Bearer header to any LLM route, such as POST /chat/completions, and reach the vulnerable query through the proxy's error-handling path. From there the attacker could issue arbitrary SELECT statements against the PostgreSQL backend.
The high-value targets are the tables that hold secrets. The litellm_credentials.credential_values column stores upstream model-provider keys, and litellm_config holds runtime configuration. Because the proxy stores credentials for every upstream provider, a single successful read exposes the keys for an organization's entire model fleet.
The fix in 1.83.7-stable replaces the string concatenation with parameterized queries. Exploitation followed disclosure quickly: Sysdig recorded the first exploitation attempt against honeypots roughly 36 hours after disclosure, and CISA added the flaw to its Known Exploited Vulnerabilities catalog on May 8, 2026.
| Detail | Value |
|---|---|
| Identifier | CVE-2026-42208 (GHSA-r75f-5x8p-qvmc) |
| Type | Pre-auth SQL injection (key verification path) |
| CVSS | 9.3 (Critical) |
| Affected | LiteLLM Proxy 1.81.16 – 1.83.6 |
| Fixed in | 1.83.7-stable (April 19, 2026) |
| Exploited | First honeypot hit ~36h after disclosure; CISA KEV May 8, 2026 |
Why this is an agentic-endpoint risk
An LLM gateway rarely sits alone. It exists because AI agents, CLIs, and developer tooling need a single place to send model traffic. On a managed endpoint, the LiteLLM process is an AI artifact in its own right, and so are the Claude Code sessions, MCP servers, and command-line agents that point at it. When the gateway holds the keys for the whole model fleet, it becomes the highest-value secret store on the host.
That concentration is the risk. A pre-auth read against one proxy does not just leak one credential; it can hand over every upstream provider key the organization uses. Those keys often grant billing authority and access to data the model can reach, so the blast radius runs well past the proxy host. Network and EDR controls see the connection but cannot tell you which agents on which endpoints were configured to route through the affected version, or what those agents were allowed to do once they reached it.
This is the same artifact-layer blind spot we track across the gateway cluster, including the sibling case in LiteLLM MCP preview remote code execution - CVE-2026-42271. The proxy is one node in a graph of AI artifacts, and you can't govern what you can't see. Fleet-wide inventory of every AI artifact is the precondition for scoping an incident like this one.
How Anomity surfaces and governs it
Anomity inventories eight AI artifact types on every managed endpoint: AI agents, MCP servers, extensions, skills, plugins, secrets, hooks, and CLIs. For CVE-2026-42208 that means the LiteLLM Proxy process and its version are catalogued alongside the agents and CLIs that route through it, so you can answer "which endpoints run an affected proxy build, and what talks to it" from the fleet inventory instead of guessing.
On agents that expose a hook, such as Claude Code PreToolUse, Anomity returns allow, deny, or log on each tool call before it runs. That is the enforcement point in runtime governance: a tool call that routes to a known-vulnerable proxy version, or that reaches a model endpoint outside policy, can be denied or logged in line rather than discovered after the fact. Anomity collects metadata only and redacts secrets on the endpoint, so it never has to read the very credentials this bug targets.
Every decision is written to a queryable 90-day audit trail. After a disclosure like this, that trail is what lets responders scope the event: which agents called through the proxy, when, and what each call was allowed to do. Anomity routes those decisions to SIEM, Slack, email, or Jira so the right team sees them in the tool they already use. The result is the timeline and the enforcement record described under outcomes.
Anomity complements your existing Network, EDR, DLP, and GRC controls rather than replacing them. It adds the agentic-endpoint layer those tools cannot see. See how it works and how Anomity compares for where it fits.
What to check across your fleet
- Identify every endpoint and service running LiteLLM Proxy and record the exact version; treat anything from 1.81.16 through 1.83.6 as affected.
- Upgrade to 1.83.7-stable or later, which replaces the vulnerable string concatenation with parameterized queries.
- Rotate every upstream model-provider key stored in the proxy, since a successful read exposes credentials for the entire model fleet.
- Rotate the proxy's own virtual keys and any shared master key, and re-issue them to the agents and CLIs that depend on them.
- Review PostgreSQL access logs for unexpected SELECT activity against litellm_credentials and litellm_config around and after April 19, 2026.
- Restrict network reachability of the proxy so it is not exposed to untrusted callers, and require authentication at the network edge.
- Enumerate which AI agents, CLIs, and MCP servers were configured to route through the affected proxy, using a fleet-wide AI artifact inventory.
- Confirm hook-based allow/deny/log enforcement is active on agents that route model traffic, so calls to a vulnerable proxy version can be blocked.
CVE-2026-42208 turns one reachable proxy into fleet-wide credential loss, which is exactly why the AI artifact layer needs its own inventory and enforcement. For the full cluster context, see the pillar on securing LLM gateways and proxies. To see Anomity inventory your agents, govern tool calls at the hook, and keep a 90-day audit trail, request early access.
Frequently asked questions
Does upgrading LiteLLM to 1.83.7 fully resolve CVE-2026-42208?
Upgrading to LiteLLM Proxy 1.83.7-stable closes the injection by replacing string concatenation with parameterized queries in the key verification path. That stops the bug, but it does not undo exposure that already happened. Any deployment that ran an affected build (1.81.16 through 1.83.6) while reachable should be treated as a potential credential read. Rotate every upstream model-provider key stored in the proxy, rotate the proxy's own virtual keys, and review database access logs for unexpected SELECT activity against litellm_credentials and litellm_config before assuming the incident is closed.
Why was an unauthenticated attacker able to reach a query behind the API key check?
The flaw lived inside the key verification path itself. When the proxy validated a caller-supplied key from the Authorization: Bearer header, it concatenated that value directly into the SQL text instead of binding it as a parameter. A crafted header sent to any LLM route, such as POST /chat/completions, reached the query through the proxy's error-handling path before authentication completed. So the attacker did not need a valid key; the act of presenting a malicious key was the injection vector.
What data could an attacker read through this vulnerability?
Because the injection runs arbitrary SELECT statements against the PostgreSQL backend, an attacker could target the tables that hold the proxy's secrets. The litellm_credentials.credential_values column stores upstream model-provider keys, and litellm_config holds runtime configuration. Since LiteLLM sits in front of an organization's entire model fleet, a single successful read can hand over the keys for every connected provider at once. That turns one proxy compromise into fleet-wide credential loss, including keys that may grant billing and data access far beyond the proxy host.
How does Anomity reduce exposure when a gateway like LiteLLM is compromised?
Anomity treats the LLM gateway as an AI artifact on the endpoint, so it inventories the LiteLLM process, its version, and the local agents and CLIs that route through it. On agents that expose a hook, such as Claude Code PreToolUse, Anomity returns allow, deny, or log on each tool call before it runs, so you can block calls that route to a known-vulnerable proxy version. Every decision lands in a queryable 90-day audit trail, giving responders the timeline they need to scope a credential-theft event.