AI gateways have become the toll booths of the LLM stack: every request passes through, every provider key sits nearby, and everyone pretends the booth is just plumbing. LiteLLM (CVE-2026-42208) just showed what happens when that toll booth has a CVSS 9.3 SQL injection and faces the internet. About 36 hours after GitHub advisory indexing, attackers were already at the window with a crafted header and a list of credential tables.

LiteLLM is an open-source proxy used by developers to route requests to providers like OpenAI, Anthropic, and AWS Bedrock. With over 45,000 stars on GitHub, it is a central hub for managing API keys, tracking costs, and logging requests. I understand the appeal. Nobody wants provider credentials scattered across services like loose screws in a drawer. But centralization also builds one neat jewelry counter, and attackers can read the sign.

The official GitHub security advisory describes a pre-authentication SQL injection rated CVSS 9.3. An attacker can send a crafted Authorization header to any proxied API endpoint. The proxy's error handling logic then incorrectly mixes that input into a database query and grants access. I have seen enough "helpful" error plumbing to know the smell: the code meant to explain the crash becomes the crowbar.

This is not the usual "oops, the users table leaked" cleanup drill. Sysdig's threat research report and The Hacker News report line up on the precise ugly bit: attackers specifically targeted the litellm_credentials table. A single row in that table can contain an OpenAI organization key with a five-figure monthly spending cap, an Anthropic key with workspace admin rights, or AWS Bedrock IAM credentials. Sysdig assessed the blast radius as closer to cloud-account compromise than a typical web-app SQL injection. The practical risk is blunt: once that row is exposed, your API budget becomes someone else's disposable compute account.

The speed is the part worth taping to the monitor. This follows the same pattern as the LMDeploy vulnerability (CVE-2026-33626), which was weaponized in just 13 hours. In both cases, attackers exploited AI infrastructure shortly after advisory indexing. The comfortable ritual of waiting for a public proof-of-concept before moving is now about as useful as putting a traffic cone in front of an open vault.

The fix is straightforward, which means there is very little room for theater. The advisory leaves three practical actions:

  1. Upgrade immediately: The vulnerability is patched in version 1.83.7-stable and later. All versions from 1.81.16 up to but not including 1.83.7 are vulnerable.
  2. Apply the workaround: If you cannot patch right away, you can mitigate the risk by setting disable_error_logs: true in your LiteLLM configuration. This blocks the specific code path the attackers are using.
  3. Assume exposure: Given the 36-hour window, treat any unpatched public-facing instance as exposed, investigate access logs, and rotate upstream LLM provider keys if exposure or compromise is suspected.

LiteLLM's second major security incident in two months, following a supply-chain attack in March, confirms what the market already knew: anything that sits between developers and expensive model providers is no longer a convenience script. It is critical infrastructure with a billing meter attached. Treat it like an edge router, not like a weekend helper library you forgot under the sink.