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.
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.