Vulnerability Details

Root Cause

The flaw exists in LiteLLM's proxy API key verification process. When a request arrives, the proxy checks the Authorization: Bearer header value against its database to authenticate the caller. In affected versions, the bearer token value was concatenated directly into the SQL query string instead of being passed as a parameterized input:

A single quote in the bearer value allows an attacker to escape the string literal and append arbitrary SQL statements. Because the injection point is in the authentication check itself, no valid credentials are needed to trigger it.

Attack Path

1. Attacker sends a crafted HTTP request to any LLM API endpoint (e.g., POST /chat/completions)
2. The Authorization: Bearer header contains a SQL injection payload
3. The request flows through the proxy's error-handling path and reaches the vulnerable query
4. The attacker can execute arbitrary SELECT or potentially INSERT/UPDATE/DELETE statements against the PostgreSQL backend
5. Database tables containing API keys, provider credentials, and configuration data are exposed

What Attackers Targeted

Sysdig's Threat Research Team observed real-world exploitation attempts targeting:

• LiteLLM_VerificationToken table -- virtual API keys and access controls
• Credential storage tables -- upstream LLM provider API keys (OpenAI, Anthropic, etc.)
• Configuration tables -- model definitions, spend budgets, rate limit settings

Exploitation Timeline

The 36-hour exploitation window is consistent with an organized threat actor using automated scanning to monitor new CVE publications and rapidly develop or adapt exploit code. SQL injection is a well-understood class of vulnerability -- once the affected code path is identified, weaponization is straightforward.

Impact Assessment

Confidentiality: High -- database contents readable, including credentials
Integrity: High -- database writable, keys can be added, modified, or deleted
Availability: Medium -- proxy can be disrupted through database modification
Authentication required: None -- fully pre-authentication
Network access required: Yes -- attacker must be able to reach the proxy port

Why this matters beyond a typical SQLi: LiteLLM is specifically designed to centralize credential management. An organization running a compromised LiteLLM instance may have configured it with API keys for OpenAI, Anthropic, Azure OpenAI, AWS Bedrock, and other providers. Each of those keys represents access to paid LLM services with potentially significant spend limits. Beyond LLM spend abuse, cloud provider credentials in the database could enable lateral movement into AWS, Azure, or GCP environments.

Affected Versions

Detection Opportunities

Network/WAF Level

Look for HTTP requests to LiteLLM endpoints containing SQL metacharacters in the Authorization header:

Indicators to hunt for in proxy logs:

• Requests to /chat/completions, /embeddings, or other API routes with malformed bearer tokens
• Bearer values containing single quotes, double dashes, UNION, SELECT, or other SQL keywords
• High volume of 4xx responses from the proxy with varied Authorization headers from the same source IP

Database Level

• Unexpected SELECT queries against LiteLLM_VerificationToken with unusual WHERE clauses
• Access to credential or configuration tables outside normal application query patterns
• New or modified API key records not created through the admin UI

MITRE ATT&CK

Recommended Actions

Immediate (if running affected versions):

1. Upgrade to LiteLLM >= 1.83.7-stable immediately
2. If internet-facing during the vulnerable window (April 19 - patch deployment), treat as a potential compromise -- do not assume unpatched = uncompromised
3. Rotate all API keys and cloud credentials stored in the LiteLLM database
4. Review proxy access logs for SQL injection indicators in Authorization headers

Short-term: 5. Restrict network access to the LiteLLM proxy port -- it should not be directly internet-facing without authentication in front of it 6. Enable database query logging to detect future injection attempts 7. Add WAF rules to inspect Authorization headers for SQL metacharacters

Ongoing: 8. Subscribe to CISA KEV alerts -- this vulnerability was being actively exploited before most patch cycles would have caught it 9. Treat AI infrastructure as high-value credential stores -- the same security controls applied to secrets managers should apply to LLM proxy deployments

Analyst Notes

Why AI infrastructure is a growing target: LiteLLM and similar tools sit at a privileged position -- they hold credentials to paid cloud services with high spend limits and are often deployed by engineering teams rather than security teams, with less mature security review. The Sysdig team specifically noted that LiteLLM operators "trust it to centralize cloud-grade credentials," making it an attractive target for credential theft and LLM service abuse (using stolen API keys to run their own queries against paid models).

The 36-hour exploitation window is a benchmark: This is not an anomaly. Threat actors actively monitor CVE publication feeds and advisory databases. For critical, pre-auth vulnerabilities in widely-used open-source software, assume exploitation begins within 24-48 hours of public disclosure. Patch SLAs need to account for this reality -- a 30-day patch window is not appropriate for CVSS 9+ pre-auth vulnerabilities.

CISA KEV as a prioritization signal: The KEV catalog only includes vulnerabilities with confirmed real-world exploitation. If a CVE appears in KEV, it is not theoretical -- someone has already used it against real targets. Organizations should treat KEV additions as immediate action items regardless of their internal CVSS-based prioritization thresholds.

References

• CISA KEV -- CVE-2026-42208
• Sysdig TRT Analysis
• The Hacker News Coverage
• Security Affairs
• GHSA-r75f-5x8p-qvmc
• MITRE ATT&CK T1190
• MITRE ATT&CK T1555