LiteLLM SQL Injection Flaw Under Active Attack Within 36 Hours

Key Takeaways

• CVE-2026-42208 is a 9.9 CVSS pre-auth SQL injection flaw in LiteLLM's proxy API key verification
• Attackers began exploitation 36 hours after disclosure, targeting tables storing API keys and provider credentials
• Organizations running exposed LiteLLM instances should upgrade to v1.83.7 and rotate all stored credentials

Attackers wasted no time. Just 36 hours after a critical SQL injection vulnerability in LiteLLM went public, hackers were already probing exposed instances for API keys, provider credentials, and configuration secrets.

The flaw, tracked as CVE-2026-42208, carries a 9.9 CVSS severity score. It requires no authentication to exploit. An attacker simply sends a crafted Authorization header to any LLM API route, and LiteLLM's proxy hands over database access.

Why LiteLLM Is a High-Value Target

LiteLLM is an open-source middleware layer that lets developers call multiple AI models (OpenAI, Anthropic, AWS Bedrock) through a single unified API. It handles authentication, rate-limiting, and credential management for an organization's entire AI infrastructure.

The project has 45,000 stars and 7,600 forks on GitHub. Developers building LLM applications and platforms managing multiple models rely on it heavily.

That popularity makes it a prime target. LiteLLM stores API keys, virtual keys, master keys, and environment secrets. Compromising its database gives attackers credentials for every AI provider an organization uses.

“The blast radius of a successful breach is closer to that of a massive cloud account compromise than to that of a typical web application attack.”

— Michael Clark, Sysdig Threat Research Team

How the Attack Works

The vulnerability exists in LiteLLM's proxy API key verification step. The original code used string concatenation to build SQL queries, a textbook mistake that enables injection attacks.

An attacker sends a request to /chat/completions with a malicious Authorization: Bearer header containing SQL injection payloads. No valid credentials needed. The database responds with whatever the attacker queries.

Sysdig researchers observed attackers targeting three specific tables: LiteLLM_VerificationToken, litellm_credentials, and litellm_config. These store the keys and secrets that matter most.

The attackers showed precision. They skipped benign tables entirely and went straight to where the secrets live. This suggests they studied the LiteLLM codebase before the attack.

Attack Timeline

In the second phase, the threat actors changed IP addresses (likely for evasion) and reran injection attempts with fewer, more precise payloads. They had already learned the correct table names and structures from phase one.

Not the First LiteLLM Security Incident

This is the second security incident involving LiteLLM in recent months. The project was previously targeted in a supply-chain attack where hackers calling themselves TeamPCP released malicious PyPI packages. Those packages deployed an infostealer designed to harvest credentials, tokens, and secrets from infected systems.

What You Should Do Now

The fix is available in LiteLLM version 1.83.7. The maintainers replaced string concatenation with parameterized queries, the standard defense against SQL injection.

• Upgrade to LiteLLM v1.83.7 or later immediately
• Treat any internet-exposed LiteLLM instance running a vulnerable version as potentially compromised
• Rotate every virtual API key, master key, and provider credential stored in exposed instances
• Check logs for requests to /chat/completions with unusual Authorization headers
• Review access to the three targeted tables: LiteLLM_VerificationToken, litellm_credentials, litellm_config

If you cannot upgrade immediately, the maintainers suggest restricting network access to your LiteLLM proxy. Only trusted internal services should reach it.

The Bigger Picture

Sysdig noted that 36 hours from disclosure to exploitation is not the fastest turnaround they have seen. A recent vulnerability in Marimo was exploited even faster. But the speed and precision of these attacks shows that threat actors are watching AI infrastructure closely.

Organizations adopting LLM tooling need to apply the same vulnerability management discipline they use for databases and authentication systems. The middleware layer between your code and AI providers is not a low-risk component. It is often the most credential-dense part of your stack.

Frequently Asked Questions

What is CVE-2026-42208?

A critical pre-authentication SQL injection vulnerability in LiteLLM's proxy API key verification. It has a 9.9 CVSS score and allows attackers to read and modify the proxy database without any credentials.

Which LiteLLM version fixes this vulnerability?

Version 1.83.7 and later. The fix replaces string concatenation with parameterized queries in the authentication code.

What data can attackers steal through this flaw?

API keys, virtual keys, master keys, provider credentials (OpenAI, Anthropic, Bedrock), and environment configuration secrets stored in LiteLLM's database.

How do I know if my LiteLLM instance was compromised?

Check logs for suspicious requests to /chat/completions with unusual Authorization: Bearer headers. If your instance was internet-exposed and running a version before 1.83.7, assume compromise and rotate all credentials.

Why are AI gateways being targeted?

They store credentials for multiple AI providers in one place. Compromising an AI gateway gives attackers access to an organization's entire AI infrastructure, including API spend and potentially sensitive data.

Source: BleepingComputer