Researchers flag LiteLLM SQL injection

- Security researchers and LiteLLM maintainers disclosed in April 2026 that CVE-2026-42208 let unauthenticated attackers reach a vulnerable API-key verification query. (docs.litellm.ai) - GitHub rated the flaw critical, affecting LiteLLM versions 1.81.16 through 1.83.6, and Sysdig said exploitation attempts appeared 36 hours after disclosure. (github.com) - LiteLLM says users should upgrade to 1.83.10-stable or later, review Postgres query history, and rotate stored provider credentials if exposed. (docs.litellm.ai)

LiteLLM users are dealing with a concrete gateway-security problem, not a vague “AI risk” story. The issue is CVE-2026-42208, a critical SQL-injection flaw in LiteLLM Proxy’s API key verification path that could let an unauthenticated attacker reach the proxy’s PostgreSQL backend by sending a crafted `Authorization: Bearer` header to an LLM API route. (docs.litellm.ai) GitHub’s advisory says the bug could allow an attacker to read data from the proxy database and potentially modify it, including credentials the proxy manages. (github.com) LiteLLM says affected versions are 1.81.16 through 1.83.6 and that patched releases start at 1.83.7, with 1.83.10-stable the recommended version. ### So what exactly was vulnerable in LiteLLM? (docs.litellm.ai) GitHub’s advisory says the vulnerable code mixed a caller-supplied key value directly into a database query during proxy API key checks instead of passing it as a separate parameter. That made the bug a classic SQL injection, but in a high-value place: the gateway path that sits in front of upstream model providers and often stores provider secrets, virtual keys and environment-backed credentials. LiteLLM’s own security note says a crafted bearer token could, “under certain conditions,” reach a vulnerable query path during API key verification. The company said practical impact depended on deployment configuration, network exposure, database permissions and what data was stored in the proxy database. (github.com) ### Why were Anthropic and AWS Bedrock part of the warning? Sysdig said LiteLLM is widely used as a front end for OpenAI, Anthropic and other model providers, while LiteLLM’s release notes describe support across Anthropic and Bedrock among other platforms. That matters because the gateway can centralize access to multiple providers behind one OpenAI-compatible interface, which means the proxy database can become a single place where upstream credentials are stored or referenced. (github.com) The warning circulating on X about Anthropic and AWS Bedrock appears consistent with that architecture, but the core flaw is in LiteLLM’s proxy layer rather than in Anthropic or Amazon’s Bedrock service itself. (docs.litellm.ai) The advisory and LiteLLM’s disclosure describe exposure of credentials “the proxy manages,” not a provider-side breach. That is an inference from the primary disclosures and architecture notes. ### Did anyone actually try to exploit it? Sysdig said its threat research team observed the first exploitation attempt 36 hours and seven minutes after the advisory was published to GitHub’s global advisory database on April 24, 2026. Sysdig described the activity as targeted schema enumeration rather than generic scanning and said the attacker probed three tables holding what it called the “highest-value secrets”: virtual API keys, stored provider credentials and environment-variable configuration. (sysdig.com) CISA added CVE-2026-42208 to its Known Exploited Vulnerabilities catalog on May 8, 2026, citing evidence of active exploitation. (github.com) That moved the bug from a patch-now advisory to a formally tracked exploited vulnerability for U.S. federal defenders. ### What should operators do now? LiteLLM says users should upgrade to 1.83.10-stable, or at minimum to 1.83.7 or later. GitHub’s advisory says that if upgrading is not immediately possible, operators can set `disable_error_logs: true` under `general_settings` to remove the path through which unauthenticated input reaches the vulnerable query. (sysdig.com) LiteLLM also says operators whose proxies were reachable from an untrusted network while running affected versions should review Postgres query history. Because the proxy may hold provider keys and other secrets, responders should also rotate any credentials stored in or accessible through the gateway if exposure is suspected. (cisa.gov) That credential-rotation step follows from the advisory’s description of possible database reads and unauthorized access to managed credentials. ### What is the concrete next check? LiteLLM’s guidance points to three immediate checks: confirm the deployed version is newer than 1.83.6, inspect Postgres query history for suspicious crafted authorization inputs, and inventory any stored upstream credentials tied to Anthropic, Bedrock or other providers for rotation. (docs.litellm.ai) CISA’s KEV entry means federal agencies and contractors will also be checking whether exposed internet-facing LiteLLM proxies were patched after May 8, 2026.

Get your own daily briefing

Scout delivers personalized news, insights, and conversations tailored to your role and industry.

Download on the App Store

Shared from Scout - Be the smartest in the room.