LiteLLM breached within 36 hours

LiteLLM is the kind of software teams put in front of expensive model APIs so one proxy can handle keys, routing, budgets, and access control. That convenience is the whole value proposition. It is also the danger. A critical SQL injection in LiteLLM’s proxy path — CVE-2026-42208 — was fixed before public disclosure, but once the advisory hit GitHub’s global database, attackers started probing real deployments within about 36 hours. (github.com) ### What is LiteLLM actually sitting in front of? LiteLLM is an AI gateway. Teams use it to front OpenAI-, Anthropic-, and Bedrock-style calls with one OpenAI-compatible endpoint, while the proxy stores upstream provider credentials, virtual API keys, budgets, and config. That means the proxy is not just a traffic router — it is a secrets concentrator. (sysdig.com)st-litellms-authentication-path-discovered-36-hours-following-vulnerability-disclosure)) ### What was the bug? The vulnerable code path checked the `Authorization: Bearer` header during API key verification, but mixed the caller-supplied value directly into a database query instead of parameterizing it. In affected versions, an unauthenticated request co(sysdig.com)` as affected. (github.com) ### Why is “pre-auth” the scary part? Because the attacker did not need a valid LiteLLM key first. If the proxy port was reachable, the attacker could try the injection before authentication happened. That collapses a lot of normal defenses. You are not dealing with a user abusing their own access. You are dealing with internet-reachable software exposing the very system that decides who gets access. (github.com) ### What did attackers do in the wild? Sysdig says the first exploitation attempt showed up on April 26, 2026, at 04:24 UTC — 36 hours and 7 minutes after the advisory became broadly visible in GitHub’s global advisory database on April 24 at 16:17 UTC. The activity came first from `65.111.27.132`, then from `65.111.25.67`, both tied to the same operator pattern. This was not broad noisy scanning. It looked targeted. (sysdig.com) ### What were they trying to steal? The interesting part is the table selection. Sysdig says the probes focused on `litellm_credentials.credential_values` and `litellm_config` — basically the places most likely to hold upstream provider keys and runtime environment data. The attacker did not spend time rummaging through lower-value user tables. That suggests they understood LiteLLM’s schema and went straight for the secrets. (thehackernews.com) ### Why does that matter more than a normal SQL injection? Because a LiteLLM row can unlock far more than the app itself. Sysdig’s point is blunt — one extracted record may hold an OpenAI org key, an Anthropic admin-capable key, or AWS Bedrock credentials. So the blast radius can look less like “someone dumped a web app database” and more l(thehackernews.com)ntrol.” (thehackernews.com) ### What should operators do right now? Upgrade to `v1.83.10-stable` if possible, or at least `v1.83.7` or later. If you cannot patch immediately, GitHub lists `disable_error_logs: true` under `general_settings` as a workaround because it removes the vulnerable path. LiteLLM also says exposed deployments should review Postgres query history for signs of probing. (docs.litellm.ai) ### Why is this story bigger than LiteLLM? Because AI gateways are becoming control planes. They sit next to billing limits, provider keys, model routing, and environment secrets. That is a very juicy position. The lesson is simple — isolate these proxies, keep credentials short-lived, lock down egress, and do not let a convenience layer quietly become your crown-jewel vault. (docs.litellm.ai)