LiteLLM, the Open-Source AI Gateway With Twenty-Two Thousand GitHub Stars, Just Patched a Pre-Authentication SQL Injection in Its API Key Verification Path. The Authorization Bearer Header Was Concatenated Directly Into a SELECT Statement Without Parameter Binding. Sysdig Caught the First Exploitation Attempt Thirty-Six Hours and Seven Minutes After the Advisory Was Published. The Attacker Knew Which Tables to Target.

WHAT THE BUG IS

LiteLLM is a popular open-source proxy that gives applications a single OpenAI-compatible REST interface to dozens of upstream LLM providers. Operators configure model definitions, virtual API keys, spend budgets, and provider credentials through an admin UI. Clients send a request with an Authorization Bearer header containing their virtual key. The proxy verifies the key, applies rate limits, and forwards the request to the chosen upstream model.

The verification step is where the vulnerability lives. In affected versions, the Bearer value is concatenated directly into a SELECT statement against the LiteLLM_VerificationToken table. No parameter binding. A single quote in the header escapes the string literal. Anything after that quote is parsed as additional SQL. The query happens before authentication is decided, so the injection is fully pre-auth. Any HTTP client that can reach a LiteLLM proxy port can issue arbitrary SELECT statements against the PostgreSQL backend without credentials.

The mechanism is identical to the SQL injection patterns the security industry documented in OWASP guidance two decades ago. The fix is identical to the fix the security industry has shipped in every web framework since: parameterized queries. LiteLLM version 1.83.7 replaces string concatenation with parameter binding and resolves the vulnerability. Anyone running an affected version (1.81.16 through 1.83.6) on an internet-reachable port has been exposed since at least April 24, the date the GitHub Advisory Database indexed the disclosure.

HOW THE ATTACK WORKED

Sysdig's Threat Research Team published detailed honeypot data on the exploitation. The first observed attempt arrived thirty-six hours and seven minutes after the advisory was indexed in the GitHub Advisory Database. The operator did not run a generic mass scan. The targeting was specific.

The payload pattern was UNION-based SQL injection. The attacker sent crafted Authorization Bearer headers to LLM API routes including the standard /chat/completions endpoint. The injection used schema-aware column-count discovery, the textbook reconnaissance approach for UNION-based extraction. Rotating egress IPs spread the request volume across multiple sources to avoid signature-based blocking. The payloads enumerated three specific tables.

The first table was LiteLLM_VerificationToken, which holds virtual API keys issued by the proxy. The second was litellm_credentials, which holds upstream provider credentials including master API keys to OpenAI, Anthropic, and AWS Bedrock accounts. The third was litellm_config, which holds the proxy's runtime environment variables. The attacker did not probe litellm_users, which would have held user identity information without the upstream secrets, or litellm_team, which would have held team membership data. The selection demonstrates schema knowledge. The operator knew which tables held the secrets they wanted and went directly to them.

Sysdig also noted a tactical detail worth highlighting. The schema knowledge required to target the right tables matches Prisma's PascalCase naming convention, which is how LiteLLM defines its database schema. The attacker either had prior familiarity with the LiteLLM schema, ran reconnaissance against a public installation to enumerate it, or used an LLM to read the LiteLLM source code and produce table names. All three options describe a sophisticated operator working at the speed of disclosure.

THE BLAST RADIUS

LiteLLM is not a typical web application. It is the credential proxy for an organization's relationship with multiple LLM providers. The blast radius of a successful database extraction is closer to a cloud account compromise than to a standard web breach.

Master API keys to OpenAI, Anthropic, and other LLM providers are in the credentials table. Master keys typically have unbounded usage authority. An attacker holding them can run arbitrary inference on the victim's account, exhaust spending limits, and access any data the keys are authorized to retrieve. For organizations using LLMs to process sensitive data through retrieval-augmented generation, the access path goes from "stole credentials" to "submitted queries against the victim's vector store" within minutes.

Virtual API keys issued by the proxy itself give attackers persistent access to the victim's LiteLLM environment for as long as the keys remain valid. Runtime environment variables in litellm_config commonly include database connection strings, third-party service credentials, and operational secrets that downstream automation depends on. The attacker who extracts those values has handed themselves the integration map of the victim's AI infrastructure.

The five-figure monthly cloud bills associated with production LLM deployments are the smaller part of this problem. The larger part is the credential reuse. Most organizations have not separated their LLM provider credentials from credentials they use for other automated workloads. A compromised LiteLLM proxy is often a compromise of broader cloud automation infrastructure that happens to terminate at LiteLLM.

THE PATTERN WE KEEP DOCUMENTING

This is the sixth AI infrastructure compromise we have written about this month, and the pattern is becoming difficult to ignore. On April 21 we covered the OX Security research on architectural RCE in Anthropic's Model Context Protocol. On April 25 we covered the LMDeploy SSRF that was exploited within thirteen hours of disclosure. On April 26 we covered the GlassWorm sleeper extensions in the marketplace that powers Cursor and Windsurf. On April 28 we covered the Silverfort research on the Microsoft Entra Agent ID Administrator role with scope overreach. Last night we published a methodology piece on reading AI prompts adversarially. Today's LiteLLM story is the textbook example for the methodology.

The thought leadership piece argued that AI infrastructure is being built by ML engineers, not by web application security specialists, and that the same input validation patterns that web frameworks have built-in defaults for are not yet built into AI-specific tooling. The LiteLLM SQL injection is exactly that thesis in concrete form. Every modern web framework defaults to parameterized queries. Django's ORM. SQLAlchemy. Active Record. Prisma itself, which LiteLLM uses for its schema layer, supports parameterized queries through its query builder. The string concatenation in LiteLLM's verification path was a deliberate choice by a developer who either did not know the security implications or chose to ship the feature before fixing them. SQL injection is not a hard problem. It is a known problem with known solutions that have been the default in mainstream code for fifteen years. The bug is now in production AI infrastructure code because AI infrastructure is being written under different conditions and reviewed by different people than the rest of the enterprise stack.

The thirty-six-hour exploitation window matters less than the cadence the window represents. The LMDeploy exploitation window was thirteen hours. The LiteLLM window was thirty-six hours. The GlassWorm sleepers waited weeks before activating. Different attack patterns operate at different speeds. The one constant is that the attackers are watching the same advisory feeds defenders are watching. They are reading the technical details. They are building exploits from the advisory text. They are landing in honeypots before most operators have updated their patch ticket queue.

INDICATORS AND TIMELINE

WHAT TO DO