TP-EXP-2026-0021 CVE-2026-42208 critical Active Exploitation AI Draft

BerriAI LiteLLM SQL Injection in Proxy API Key Verification (CVE-2026-42208)

CVE CVE-2026-42208 Platform BerriAI LiteLLM Type SQL Injection
Severity CRITICAL
Status Active Exploitation
Zero-Day Confirmed
Disclosed April 24, 2026
Patched April 24, 2026
Researcher Tencent YunDing Security Lab CISA KEV Listed

CVE-2026-42208 is a SQL injection vulnerability (CWE-89) in BerriAI LiteLLM, an open-source AI gateway and proxy server used to route requests to LLM APIs. An unauthenticated attacker can send a specially crafted Authorization header to any LLM API route exposed by the proxy and reach an unsanitized database query through the error-handling path in the API key verification logic. Successful exploitation allows an attacker to read and potentially modify data in the proxy’s database, including stored LLM API keys and other credentials the proxy manages. CISA added CVE-2026-42208 to the Known Exploited Vulnerabilities catalog on May 8, 2026, with a mandatory remediation deadline of May 11, 2026.

Severity Assessment

  • Exploitability: 9/10
  • Impact: 8/10
  • Weaponization Risk: 9/10
  • Patch Urgency: 10/10
  • Detection Coverage: 4/10

Exploitability (9/10): The vulnerability requires no authentication (CVSS 4.0 PR:N), no user interaction (UI:N), no special attack prerequisites (AT:N), and is reachable over the network (AV:N) with low attack complexity (AC:L). Any system capable of sending HTTP requests to a LiteLLM proxy instance can attempt exploitation. The attack entry point is the Authorization header on any LLM API route, which is a standard interface deliberately exposed to external callers.

Impact (8/10): Successful exploitation yields read access to the proxy’s database with potential write access as well. The database contains LLM API keys, user credentials, and configuration data that the proxy uses to authenticate requests to upstream LLM providers including OpenAI, Anthropic, and others configured in the proxy. An attacker who exfiltrates these keys gains the ability to make API calls at the proxy owner’s expense and access any data accessible through those upstream provider accounts. Organizations running LiteLLM in enterprise or production environments may have consolidated API keys across multiple providers, multiplying the downstream impact.

Weaponization Risk (9/10): SQL injection is a well-documented and heavily tooled vulnerability class. The attack path can be implemented with standard SQLi techniques: a crafted Authorization header that reaches an interpolated SQL query requires no special tooling. CISA’s inclusion in the KEV catalog confirms active exploitation in the wild. The unauthenticated attack surface (no authentication, a standard HTTP header) means this is within reach of automated exploitation frameworks and opportunistic actors, not only targeted threat actors.

Patch Urgency (10/10): CISA’s mandatory remediation deadline for federal agencies is May 11, 2026, three days after KEV addition. LiteLLM is deployed as centralized AI infrastructure that concentrates API keys for multiple upstream providers. A compromised proxy exposes all API keys it manages simultaneously. The fix is available as version 1.83.7, and a workaround exists for organizations that cannot immediately upgrade.

Detection Coverage (4/10): The attack arrives as a crafted Authorization header in an otherwise legitimate-looking HTTP request to a normal API endpoint. Without application-layer inspection or SQL query auditing in the proxy’s database layer, the initial injection attempt is unlikely to generate alerts in standard infrastructure monitoring. Database logs capturing raw query text would be required for detection at injection time. Post-exploitation patterns may be detectable with baseline monitoring, but these appear only after credential exfiltration has already occurred.

Summary

CVE-2026-42208 affects BerriAI LiteLLM versions 1.81.16 through 1.83.6 (inclusive). LiteLLM is an open-source proxy server and AI gateway designed to present a unified OpenAI-compatible interface to a variety of LLM backends. Organizations use it to centralize API key management, apply rate limiting and cost controls, implement routing logic, and log LLM usage across teams and applications.

The vulnerability exists in the code path that verifies API keys during proxy request handling. When a caller presents an Authorization header with an API key value, LiteLLM queries its database to validate the key. In vulnerable versions, the caller-supplied key value was interpolated directly into the SQL query string rather than being passed as a separate parameterized value. An attacker can supply a key value containing SQL meta-characters to alter the structure of the query, causing the database to execute attacker-controlled SQL statements. The error-handling path in this verification logic provides the reachable code path that an unauthenticated caller can trigger.

Affected versions:

  • BerriAI LiteLLM: >= 1.81.16, < 1.83.7

Fixed version:

  • BerriAI LiteLLM 1.83.7 (released as v1.83.7-stable)

Workaround: Organizations that cannot immediately upgrade should set disable_error_logs: true under general_settings in the LiteLLM configuration. This removes the code path through which unauthenticated input reaches the vulnerable SQL query, mitigating exploitation until an upgrade is possible.

Exploitation context: CISA’s KEV addition indicates this vulnerability is being actively exploited. LiteLLM deployments in multi-user enterprise environments or SaaS platforms that aggregate API keys across many upstream providers represent targets for credential theft. A single successful injection against such a deployment could yield multiple LLM provider API keys, user tokens, and configuration data in a single operation.

Exploit Chain

Stage 1: Target Identification

Adversaries identify LiteLLM proxy instances through observable signals. LiteLLM exposes a default landing page, Swagger UI, and model listing endpoint (/models) that collectively fingerprint the software and version. Public-facing deployments may be discoverable via internet scanning tools searching for characteristic HTTP response patterns. Internal deployments may be reachable via standard enterprise network access or compromised adjacent hosts.

Stage 2: Crafted Authorization Header Construction

The attacker constructs an HTTP Authorization header containing SQL injection payload material. The Bearer token value is crafted to include SQL meta-characters (single quotes, comment sequences such as --, or UNION-based statements) that, when interpolated into the database query string, alter query semantics. The target endpoint is any LLM API route, for example POST /chat/completions, that the proxy handles.

Stage 3: Error-Path Trigger

LiteLLM’s API key verification logic queries the database to look up the provided key. In vulnerable versions, the verification code reaches the unsanitized query in the error-handling path when the presented key value does not match a stored key. This path is reliably triggered by sending any crafted value as the Authorization header, as the attacker deliberately provides a value that will fail the initial lookup and route through the vulnerable error path.

Stage 4: SQL Injection Execution

The unsanitized key value is interpolated into the SQL query text and executed against the proxy’s database. Depending on the injected payload, the attacker can enumerate database tables, retrieve stored LLM API keys and user credentials, read configuration data, or attempt to modify database records. Boolean-based, error-based, and UNION-based injection techniques are all applicable depending on query structure and database engine.

Stage 5: Credential Exfiltration

With database read access established, the attacker extracts LiteLLM’s stored credentials. These include API keys for upstream LLM providers (OpenAI, Anthropic, Cohere, and others configured in the proxy), virtual key entries for proxy users, and any secrets stored in the LiteLLM configuration database. Extracted keys enable subsequent impersonation of the proxy’s LLM provider accounts.

Stage 6: Post-Exploitation Access

Using exfiltrated API keys, the attacker can make direct API calls to upstream LLM providers outside the proxy, access any data pipelines or integrations connected through those provider accounts, impersonate the proxy owner’s identity with LLM providers, and incur compute costs against the victim’s account. If the LiteLLM proxy also manages credentials for enterprise identity systems or datastores, those may be accessible through the same database read.

Detection Guidance

Database query logging: Enable query logging on the database backend used by LiteLLM (PostgreSQL or SQLite) and alert on queries containing SQL meta-characters in what should be opaque API key values. Legitimate API key lookups should not include characters such as ', --, ;, UNION, or SELECT in the key parameter.

HTTP request inspection: Deploy a Web Application Firewall or API gateway with SQL injection detection rules on traffic to LiteLLM proxy endpoints. Payloads that trigger this vulnerability will contain SQL injection patterns in the Authorization header’s Bearer token value, which is anomalous for normal API key usage.

LLM provider API key usage anomalies: Monitor upstream LLM provider account usage for calls originating outside expected LiteLLM proxy egress IPs or IAM contexts. Direct API calls using keys normally only exercised through the proxy indicate those keys may have been exfiltrated.

LiteLLM error log volume: A spike in API key verification failures may indicate an adversary probing or iterating injection payloads. This is especially relevant if disable_error_logs is not set and error logs are enabled.

Patch verification: Confirm that the installed LiteLLM version is 1.83.7 or later. The fix in 1.83.7 ensures the caller-supplied key value is always passed to the database driver as a separate bound parameter rather than interpolated into query text.

Indicators of Compromise

SQL injection via HTTP header does not produce traditional file-based or binary indicators. Network-observable signals associated with exploitation include:

Network Indicators

  • Authorization header Bearer token values containing SQL special characters: ', ", --, /*, */, ;, UNION, SELECT, INSERT, UPDATE, DELETE, DROP, EXEC, CAST, CONVERT
  • Repeated 4xx HTTP responses to LLM API routes from a single source IP with varied Authorization header values

Log Indicators

  • Database query logs showing dynamically constructed SQL containing user-supplied input in the WHERE clause of API key lookup queries

Behavioral Indicators

  • Anomalous upstream LLM provider API usage from unexpected source IP addresses following access to a LiteLLM instance
  • LiteLLM database access patterns inconsistent with normal request volume (e.g., bulk SELECT operations not correlated with proxy request traffic)

Disclosure Timeline

  • 2026-04-24 — BerriAI publishes GitHub Security Advisory GHSA-r75f-5x8p-qvmc

    BerriAI discloses the SQL injection vulnerability in LiteLLM API key verification. LiteLLM version 1.83.7 (v1.83.7-stable) released concurrently as the patched version. Discovery credited to Tencent YunDing Security Lab.

  • 2026-05-04 — Advisory updated on GitHub

    Advisory updated with additional patch and workaround clarifications.

  • 2026-05-08 — NVD assigns CVE-2026-42208 and CISA adds to KEV

    NVD publishes the entry with a CVSS 4.0 score of 9.3. CISA adds CVE-2026-42208 to the Known Exploited Vulnerabilities catalog, confirming active exploitation in the wild. Mandatory remediation deadline set for May 11, 2026.

  • 2026-05-11 — CISA mandatory remediation deadline

    Remediation deadline for all US federal agencies.

Sources & References

zero-daylitellmberriaisql-injectioncwe-89ai-gatewayllm-proxyunauthenticatedcredential-theftcisa-kevapi-security