LiteLLM Critical SQL Injection: Read All API Keys Without Credentials

The AI unified interface library LiteLLM, with 95 million monthly downloads, has been found to contain a critical SQL injection vulnerability (CVE-2026-42208). Attackers can read every model API key stored in the database—including OpenAI, Anthropic, Google, AWS, and others—without any valid credentials, simply by crafting a specific Bearer token that injects a payload into authentication failure logs.

Affected versions are >= 1.81.16 and < 1.83.7, and the issue has been fixed in v1.83.7-stable. Given LiteLLM’s popularity among AI engineers and its unique role as a “key relay station”, the real-world impact of this vulnerability may be far greater than expected.

---

Details: Authentication Failure Logs Became the Attack Entry Point

LiteLLM’s Proxy component validates the Bearer token before processing API requests. If the token is invalid, the system logs an error that includes the token string. The problem lies here: during error log generation, the token string was concatenated directly into the SQL query without any escaping or parameterization.

An attacker can craft an HTTP Authorization header containing an SQL injection payload, such as:

Authorization: Bearer sk-xxx' UNION SELECT api_key FROM litellm_verificationtoken--

When LiteLLM processes this token and logs the authentication failure, the malicious SQL is executed. Because the error message is often returned to the client (or logged in an accessible file), the attacker can extract the result—the stored API keys—from the response or log.

No valid credentials, no authentication, not even knowledge of the database structure are required (LiteLLM’s schema is public). If a LiteLLM Proxy instance is exposed to the internet, anyone can attempt this attack.

---

Why This Vulnerability Is Especially Dangerous

If this were an ordinary web app, an SQL injection would usually affect only that app’s data. LiteLLM is different: its core purpose is acting as a unified proxy layer for multiple model providers, which means:

1. High key concentration: One LiteLLM instance may store dozens of different providers’ keys. Attackers get not one key but a cross-provider collection.

2. Large lateral impact: These keys belong to paid accounts. Attackers can drain victims’ usage quotas or use premium keys (e.g., GPT-4) for large-scale data scraping.

3. Hard to detect: The attack occurs during authentication failure; it won’t trigger normal workflow logs. Without specific monitoring for SQL anomalies in error logs, admins might never notice.

4. Frequent public exposure: Many teams deploy LiteLLM Proxy publicly for easy internal use—essentially naked exposure under this vulnerability.

Threat intelligence from ThreatBook shows that since the vulnerability was indexed on April 28, attackers have begun scanning and exploiting exposed instances. A Sysdig report noted that targeted attack traffic appeared within 36 hours of disclosure.

---

This Isn’t LiteLLM’s First Security Incident

If you follow AI open-source supply chain security, you’ll know LiteLLM. Just one month ago (March 24), LiteLLM suffered a severe supply chain poisoning attack.

Timeline of that attack:

• Mar 19: Open-source vulnerability scanner Trivy was compromised.
• Mar 23: Hackers breached Checkmarx KICS.
• Mar 24: Hackers used the poisoned Trivy in LiteLLM’s CI/CD pipeline to steal its PyPI token, publishing two malicious versions (1.82.7 and 1.82.8).

These malicious versions did the following:

• Enumerated all sensitive data: SSH keys, .env files, cloud credentials, k8s configs, Git credentials, etc.
• Encrypted with RSA-4096 + AES-256-CBC and exfiltrated to hacker servers.
• If a k8s token was found, used it to install backdoors for lateral spread.

Worse, version 1.82.8 dropped a .pth file into site-packages. Python automatically executes import lines in .pth files at interpreter startup, meaning any Python process in that environment would execute malicious code—Flask, Jupyter, pytest, anything—not just LiteLLM imports.

These versions were online for roughly 3 hours; with 3.4 million daily downloads, roughly 420,000 instances installed malicious versions. The scale of stolen data is unknown, but many k8s clusters and API credentials were definitely compromised.

Interestingly, the hacker code contained a looping bug that exhausted resources—without this bug exposing the anomaly, LiteLLM’s poisoning might never have been discovered. Researchers believe the bug came from poorly tested AI-generated malware code.

---

Why LiteLLM Is a High-Risk Target

LiteLLM’s role among AI engineers is comparable to Axios for frontend developers or Requests for backend: not the core framework, but nearly every project uses it. Its mission is to unify API differences between model providers, enabling a single interface to call GPT, Claude, Gemini, DeepSeek, and hundreds more.

That design causes two inherent problems:

1. Wide dependency scope: Frameworks like DSPy, CrewAI, and LangChain depend on LiteLLM. When LiteLLM breaks, the downstream ecosystem suffers.

2. High key concentration: LiteLLM must store multiple providers’ credentials in environment variables or servers, often high-privilege production keys, not limited test ones.

Combined with its deployment as a centralized proxy service shared across internal projects, LiteLLM effectively becomes a key vault. Breaching one instance yields credentials spanning multiple projects and providers.

From an attacker’s viewpoint, LiteLLM is an ideal target:

• Massive deployment (95M monthly downloads)
• High-value keys (paid production accounts)
• Low attack cost (open-source, clear attack surface)
• High stealth (few teams monitor supply chain security)

---

What You Need to Do Now

If you use LiteLLM directly or indirectly through other frameworks, act immediately:

1. Verify Your Version

pip show litellm

If your version is between 1.81.16 and 1.83.6, you’re vulnerable. If it’s 1.82.7 or 1.82.8, you must handle the supply-chain poisoning incident.

2. Upgrade to a Safe Version

pip install --upgrade litellm==1.83.7

Or lock the version in requirements.txt / pyproject.toml:

litellm==1.83.7

3. Rotate All API Keys

This step is mandatory, even if your instance wasn’t publicly exposed. You can’t be sure no one exploited the bug before the patch.

Keys to rotate include (but aren’t limited to):

• OpenAI API keys
• Anthropic API keys
• Google AI API keys
• AWS Bedrock credentials
• Azure OpenAI credentials
• Any others configured in LiteLLM

4. Check Your Logs

Search your access logs for abnormal Bearer tokens containing SQL keywords (UNION, SELECT, --). If found, your instance was likely attacked.

5. Temporary Mitigation

If you cannot upgrade yet, disable error logs:

general_settings:
  disable_error_logs: true

This blocks the attack vector, but it’s only temporary—you must still upgrade and rotate keys.

---

The Bigger Problem: Fragile AI Open-Source Supply Chains

Two LiteLLM incidents in one month highlight systemic weaknesses in AI open-source supply chain security.

Missing Dependency Locking

AI evolves rapidly, frameworks update constantly, and many developers install packages without pinning versions—a near-suicidal practice against supply chain threats.

In the March poisoning, many victims used CI/CD or Docker scripts containing plain pip install litellm, pulling malicious versions automatically.

If you use uv, version locking in uv.lock happens by default. For poetry or pip-tools, ensure CI/CD and Docker installs only from lock files.

Chaotic Key Management

Many AI projects still manage secrets by writing API keys into .env files—fine for local dev, risky in production or when committed (even privately) to Git.

Better practices:

• Use professional secret managers (AWS Secrets Manager, HashiCorp Vault)
• Use distinct keys for dev/test/prod environments
• Rotate keys regularly
• Apply usage restrictions (rate limits, IP allowlists)

Blind Trust in Upstream Dependencies

In March, the initial compromise was Trivy, a security scanner embedded in countless pipelines. Few imagine their security scanner itself could be breached.

This exposes a deeper issue: blind trust in upstream dependencies. You might audit your project code—but do you audit Trivy, pytest, or pip? Unlikely. Cost is too high; update cycles too fast.

Attackers exploit exactly that. They target your toolchain, not your project. Once the toolchain is poisoned, all dependent projects fall victim.

---

Lessons for AI API Aggregation Platforms

LiteLLM’s issue is also a warning for aggregation platforms (like OpenAI Hub): key management is the core security boundary.

Such platforms inevitably store numerous users’ API keys, making them prime attack targets. A breach leaks not one user’s key—but everyone’s.

Architectural recommendations:

1. Encrypted key storage: Keys must be encrypted in databases; never appear unmasked in logs or error messages.
2. Least privilege: Application code shouldn’t directly access the key table; use a dedicated credential service with strict access controls and audit logs.
3. Anomaly detection: Monitor call patterns—sudden spikes or source changes should trigger alerts.
4. Regular audits: Review not only code but dependencies, CI/CD pipelines, and configurations for attack exposure.

LiteLLM’s SQL injection is a trivial mistake—missing parameterization—but in a system holding large volumes of valuable credentials, the outcome is catastrophic. This reminds all AI infrastructure teams: there are no small mistakes in key management.

---

Final Thoughts

Two major LiteLLM security incidents in a month can’t be chalked up to bad luck. They reveal deep flaws in its secure development practices:

• An OWASP Top 10-level bug like SQL injection should’ve been caught in code review.
• PyPI tokens shouldn’t sit directly in CI/CD environment variables; use secure storage.
• Upstream dependencies (like Trivy) need independent verification—don’t trust blindly.

For developers, updating and rotating keys isn’t enough—you must re-examine dependency and secret management strategies. Supply chain attacks targeting AI ecosystems will only grow; prepare for the long term.

If you use aggregation platforms like OpenAI Hub, key management responsibility transfers to the provider—assuming its security is sound. But if you self-host LiteLLM, you bear that responsibility yourself. This incident proves: that responsibility is heavier than most realize.

---

References

• LiteLLM SQL Injection – Read API Keys Without Credentials – Linux.do – Initial disclosure by ThreatBook Intelligence.
• LiteLLM has SQL Injection in Proxy API Key Verification – GitHub Advisory Database – Official GitHub security advisory with CVSS score and technical details.
• LiteLLM SQL Injection Vulnerability (Versions >= 1.81.16, < 1.83.7) – Linux.do – Community discussion and impact analysis.