LiteLLM Proxy SQL Injection (CVE-2026-42208, CISA KEV 2026-05-08)
LiteLLM proxy is a gateway many AI agent systems use to route requests to LLMs and manage teams, users, models, and API keys. Its admin/team-management endpoints built SQL queries by directly inserting identifiers like team_id or user_id instead of using safe parameterized queries, letting an attacker inject SQL commands through the API. CISA added this to its Known Exploited Vulnerabilities catalog, meaning it has been seen used in the wild.
How the attack works
An attacker sends a request to a LiteLLM proxy management endpoint (team, user, model, or key operations) with SQL metacharacters embedded in an identifier field instead of a normal value. Because the proxy inserted that value straight into a SQL query without sanitizing it, the injected SQL runs against the backend database. This can let an attacker read, modify, or delete data the proxy manages, including team configuration, user records, and API keys. The detection watches agent request payloads sent to LiteLLM-style endpoint paths for classic SQL injection patterns.
Netzilo detection
Netzilo reports this behaviour when it is observed.
- Signature ID
- 3d80c8a2-2170-4022-af3e-048f9149307b
- Severity
- Critical
- CVEs
- CVE-2026-42208
Why it matters
A successful exploit can expose or corrupt the proxy's database, including API keys and access control data, and could let an attacker escalate privileges or hijack how the agent's requests are routed.
What you can do
- →Patch LiteLLM proxy to a version that parameterizes these queries; treat this as urgent given the KEV listing and short federal remediation deadline.
- →Restrict network access to LiteLLM admin/team-management endpoints to trusted internal sources only.
- →Review proxy access logs for identifier fields containing SQL metacharacters (quotes, semicolons, comment sequences, UNION/SELECT keywords).
- →Rotate API keys and audit team/user records if you find evidence of injection attempts or cannot confirm the patched version was deployed before now.
Known benign look-alikes
- Database tutorial content showing SQL injection examples — rule deliberately fires when these patterns appear in agent I/O context, regardless of educational intent.
- Security research papers cited inside agent contexts — these are intentional matches and should be evaluated case-by-case.
- PR descriptions discussing SQLi fixes — match expected; signal that the fix discussion is reaching agent I/O.