"A database query used during proxy API key checks mixed the caller-supplied key value into the query text instead of passing it as a separate parameter," LiteLLM maintainers said in an alert last week.
CVE-2026-42208 and affected LiteLLM versions
The flaw, tracked as CVE-2026-42208 with a CVSS score of 9.3, is an SQL injection in the LiteLLM Python package that allows an unauthenticated caller to reach a vulnerable database query through the proxy's error-handling path. The bug affects versions >=1.81.16 and <1.83.7. The maintainers released a fix in version 1.83.7-stable on April 19, 2026.
Timeline: disclosure, advisory indexing, and first recorded exploit
Public information shows rapid follow-on abuse. The first exploitation attempt was recorded on April 26 at 16:17 UTC, roughly 26 hours and seven minutes after the GitHub advisory was indexed in the global GitHub Advisory Database, and within the broader "within 36 hours" window noted in reporting. Sysdig attributed the initial SQL injection activity to IP address 65.111.27[.]132.
Attacker behavior: two phases, targeted tables, and IP hopping
Security researcher Michael Clark and Sysdig observed a two-phase operation executed by a single operator. Malicious activity began from 65.111.27[.]132, then — about 20 minutes later — continued from an adjacent egress IP, 65.111.25[.]67, which reused similar probes after the first phase. Clark said the sequence consisted of two phases driven by the same operator across two adjacent egress IPs, followed by a brief unauthenticated probe of the key-management endpoints.
The attacker specifically targeted database tables such as "litellm_credentials.credential_values" and "litellm_config" — tables that hold upstream LLM provider keys and proxy runtime environment information — while probes did not appear against tables like "litellm_users" or "litellm_team." That selective targeting indicates the operator focused on tables containing sensitive secrets rather than user or team records.
Risk and scale: credentials, blast radius, and project reach
Sysdig detailed the stakes: "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." In other words, a successful extraction could produce the sort of access more akin to a cloud-account compromise than a routine web-app SQL injection, Sysdig said.
LiteLLM is widely used and visible in open source: the project has over 45,000 stars and 7,600 forks on GitHub. The project was also the target of a supply chain attack last month attributed to the TeamPCP group that sought credentials and secrets from downstream users — a recent precedent that raises the consequences of any database extraction from a widely deployed proxy.
Mitigation: patching, configuration workaround, and recommended steps
Maintainers and defenders have issued clear guidance. Users are advised to upgrade to the patched release (1.83.7-stable). For operators unable to apply the update immediately, the maintainers recommend setting "disable_error_logs: true" under "general_settings" to remove the error-handling path through which untrusted input reached the vulnerable query.
Sysdig characterized the advisory as part of an emergent pattern in AI-infrastructure vulnerabilities: "critical, pre-auth, and in software with five-figure star counts that operators trust to centralize cloud-grade credentials." The firm added that the "36-hour exploit window is consistent with the broader collapse documented by the Zero Day Clock," and that operator behavior — including use of verbatim Prisma table names, three-table targeting, and deliberate column-count enumeration — shows exploitation is occurring without waiting for public proof-of-concept code.
What this means for LiteLLM users, cloud providers, and security teams
- LiteLLM users: Patch to 1.83.7-stable as the primary mitigation; if patching is delayed, apply the "disable_error_logs: true" setting to remove the vulnerable path.
- Cloud providers and credential holders: Review any credentials managed through LiteLLM proxy instances, since a single credential row can contain high-privilege keys and spend-capable organization keys.
- Security teams and incident responders: Treat any successful database extraction as potentially a cloud-account compromise rather than a confined web-app incident, and investigate egress IPs such as 65.111.27[.]132 and 65.111.25[.]67 if observed in logs.
The sequence recorded here — rapid disclosure, public advisory, and near-immediate exploitation that targeted credential-bearing tables — underscores a recurring dynamic: public advisories and the open-source schema together can be sufficient to enable attackers. As Sysdig put it, "The advisory and the open-source schema were ultimately enough." Organizations that centralize cloud-grade credentials in popular tooling will face pressure to harden and accelerate patching processes; the next test will be whether patch adoption outpaces the next wave of rapid exploit activity.
