CVE-2026-42208: Your AI Gateway Has a SQL Injection. On the Auth Path.

#SQL injection. In 2026. On the authentication path. Of an AI proxy.

I genuinely thought we were past this. SQL injection has been on the OWASP Top 10 since 2003. There are entire college courses about how not to do this. Every security training ever created covers parameterized queries. And yet.

CVE-2026-42208. LiteLLM. The code that validates your API key concatenates the user-supplied key value directly into a SQL query instead of using a parameterized query. The injection is reachable through the error-handling path, so you don't even need a valid key. Just send a crafted Authorization header to any LLM API route and you're in the database.

CVSS 9.8. Added to CISA's KEV catalog on May 8. First exploitation observed 36 hours after disclosure.

36 hours. From "vulnerability published" to "your AI keys are stolen." That's the window.

#What LiteLLM is and why you should care.

LiteLLM is a proxy/gateway that sits between your applications and your AI model providers (OpenAI, Anthropic, Google, Cohere, etc.). It manages API keys, routing, rate limiting, cost tracking, and load balancing. It's the central nervous system for a lot of enterprise AI deployments.

If you use multiple AI providers, there's a decent chance LiteLLM is involved somewhere in your stack. Or something like it. The architecture pattern of "AI proxy that holds all the keys" is everywhere.

When the attacker SQLi's through the auth path, they get access to the LiteLLM database. What's in that database?

• Every upstream AI provider API key your organization uses (OpenAI, Anthropic, etc.)
• Runtime configuration and routing rules
• Usage data, cost tracking, and billing information
• User/team access tokens

With your OpenAI key, the attacker can run inference on your dime. With your Anthropic key, same thing. They can rack up thousands of dollars in API charges. They can exfiltrate any data your AI workflows process. They can poison your model responses if they have write access to the proxy configuration.

And since these proxies often sit as the auth layer for enterprise AI workflows, compromising one proxy cascades to every AI service behind it.

#The pattern keeps repeating with AI tools.

I've been writing about this for weeks now and the theme is always the same: AI infrastructure is being deployed without basic security hygiene.

• CVE-2026-48710 (BadHost): one character in a Host header bypasses auth on FastAPI/Starlette, the framework under most Python AI services
• CVE-2026-39987 (Marimo): pre-auth RCE in a Python notebook, attacker used an LLM agent for post-exploitation
• Now CVE-2026-42208: SQL injection in the AI proxy's auth path

The AI stack is the new attack surface. These aren't obscure research tools. LiteLLM alone is the routing layer for thousands of production AI deployments. And it has a SQL injection. On the auth path. In 2026.

We keep building new things on top of broken foundations and then acting surprised when they fall over.

#What to do.

If you run LiteLLM:

1. Upgrade to 1.83.7-stable or later immediately. This is on CISA KEV. Federal agencies have a hard deadline. You should treat it the same way.

1. Rotate every upstream API key stored in LiteLLM. Assume they're compromised. OpenAI, Anthropic, Cohere, whatever you have configured. Regenerate all of them.

1. Audit your LiteLLM access logs for unusual requests to LLM API endpoints with malformed Authorization headers. SQLi attempts leave traces.

1. Restrict network access to your LiteLLM instance. It should not be directly reachable from the public internet. Put it behind a VPN, IP allowlist, or at minimum a WAF.

If you use any AI proxy/gateway:

1. Inventory what credentials it stores. Every AI gateway holds API keys, tokens, and configuration. Understand what's at risk if the gateway gets compromised.

1. Treat your AI infrastructure like critical infrastructure. Because it is. It holds the keys to your AI providers, your data flows through it, and a single vulnerability exposes everything.

1. Monitor for anomalous AI API usage. Sudden spikes in API calls, requests from unexpected IPs, model access outside normal patterns. These are signs someone else is using your keys.

#Further reading

• NVD: CVE-2026-42208 - official vulnerability entry
• Bishop Fox Analysis - technical deep dive
• Sysdig: Exploitation 36 Hours Post-Disclosure - incident timeline
• OWASP SQL Injection Prevention - how to not make this mistake
• CISA KEV Catalog - actively exploited vulnerabilities