A critical pre-authentication SQL injection vulnerability in BerriAI’s LiteLLM AI gateway, tracked as CVE-2026-42208, has been actively exploited in the wild with threat actors weaponizing the flaw within just 36 hours of its public disclosure, putting AI infrastructure credentials across hundreds of organizations at severe risk.
CISA officially added CVE-2026-42208 to its Known Exploited Vulnerabilities (KEV) catalog on May 8, 2026, imposing a compliance deadline of May 11, 2026, for federal agencies to remediate or discontinue use of the affected product.
The rapid escalation from disclosure to active exploitation underscores the growing risk that adversaries will treat AI-facing middleware as high-value targets.
LiteLLM is a widely adopted open-source AI gateway developed by BerriAI that allows organizations to call multiple large language model (LLM) APIs, including OpenAI, Anthropic, AWS Bedrock, Azure OpenAI, and Google Vertex, through a single unified interface.
With over 22,000 GitHub stars, LiteLLM handles critical functions including API key management, rate limiting, cost tracking, and request routing across providers. Because it sits at the intersection of AI applications and cloud model providers, a compromise of the LiteLLM proxy effectively grants an attacker the “master keys” to an organization’s entire AI stack.
CVE-2026-42208: LiteLLM SQL Injection Vulnerability
CVE-2026-42208 is classified under CWE-89 (Improper Neutralization of Special Elements Used in an SQL Command), with a CVSS score of 9.3 (Critical). The flaw affects LiteLLM versions 1.81.16 through 1.83.6 and stems from a fundamental input validation failure in the proxy’s API key verification pathway.
Specifically, a database query executed during proxy API key checks directly concatenated the caller-supplied Authorization header value into the SQL query string rather than passing it as a separate, sanitized parameter.
This classic SQL injection anti-pattern means that an unauthenticated remote attacker can craft a malicious Authorization: Bearer header and send it to any LLM API endpoint, such as POST /chat/completions triggering the vulnerable database query through LiteLLM’s error-handling path.
Researchers, who independently reproduced and confirmed the vulnerability in a lab environment, identified two exploitation paths:
- Path B (Default Docker Deployment): Reachable in standard deployments where Python assertions are enabled. The failure callback fires on every non-
sk-prefixed Bearer token, reaching the vulnerable query. - Path A (Hardened Deployments with
-Oflag): Still exploitable via source-level analysis even when assertions are stripped, meaning hardened environments are not immune.
Demonstrating how an attacker could recover virtual API keys via SQL injection, replay them against authenticated endpoints, and ultimately achieve Remote Code Execution (RCE) within the LiteLLM container.
The consequences of a successful exploit extend far beyond the LiteLLM instance itself. Because the gateway centrally manages credentials for all connected AI providers, exploitation can result in:
- Mass credential theft: API keys for OpenAI, Anthropic, AWS, GCP, Azure, and other connected providers are stored in the proxy database, making them accessible to the attacker.
- Prompt and response log exposure: LiteLLM logs prompts and responses by default, potentially exposing customer PII, internal documents, source code, and credentials embedded in AI copilot sessions.
- Unauthorized AI resource abuse: Stolen provider credentials with elevated quotas can be weaponized for large-scale, cost-fraudulent AI usage.
- Lateral movement across cloud infrastructure: Cloud IAM keys, Kubernetes service account tokens, and database passwords accessible through the LiteLLM environment may enable deeper network penetration.
Given that LiteLLM deployments are often internet-facing for accessibility, there is no authentication barrier between an attacker and the vulnerable endpoint. A single crafted HTTP request is all that is required to initiate exploitation.
Threat actors began actively targeting CVE-2026-42208 in the wild within 36 hours of its public disclosure, one of the fastest exploitation windows recorded for an AI-infrastructure-targeting vulnerability. Security researchers confirmed targeted SQL injection activity against LiteLLM’s authentication path in real-world honeypots following the advisory release.
The Belgian Center for Cybersecurity (CCB) also issued an emergency advisory urging organizations to patch immediately, noting that exploitation enables an unauthenticated remote attacker to extract all stored API keys and provider credentials.
Mitigation
BerriAI patched CVE-2026-42208 in LiteLLM version 1.83.7, with a further stable release at v1.83.10-stable. Organizations running any version from 1.81.16 through 1.83.6 should treat the environment as potentially compromised.
Recommended remediation steps include:
- Upgrade immediately to LiteLLM v1.83.7 or later (v1.83.10-stable recommended).
- Rotate all managed credentials, including OpenAI, Anthropic, AWS/GCP/Azure IAM keys, Kubernetes service account tokens, and database passwords.
- Audit deployment logs to determine if versions 1.81.16–1.83.6 were ever installed in production, CI/CD pipelines, or Docker builds.
- Restrict network exposure of the LiteLLM proxy and, where feasible, enforce IP allowlisting.
- Deploy a Web Application Firewall (WAF) to detect and block malicious
Authorizationheader payloads targeting the SQL injection path.
FAQ
Q1: What is CVE-2026-42208?
CVE-2026-42208 is a critical (CVSS 9.3) pre-authentication SQL injection vulnerability in BerriAI’s LiteLLM AI gateway that allows unauthenticated attackers to read and modify the proxy database, exposing all managed API keys and credentials.
Q2: Which LiteLLM versions are affected by CVE-2026-42208?
All LiteLLM versions from 1.81.16 to 1.83.6 are vulnerable; the issue is patched in version 1.83.7 and later.
Q3: Is CVE-2026-42208 being actively exploited?
Yes, active exploitation in the wild was confirmed within 36 hours of the vulnerability’s public disclosure, with threat actors targeting internet-facing LiteLLM proxy instances.
Q4: What is the CISA deadline to fix CVE-2026-42208?
CISA added CVE-2026-42208 to its KEV catalog on May 8, 2026, with a mandatory remediation deadline of May 11, 2026, for federal agencies under BOD 22-01.
Site: thecybrdef.com
For more insights and updates, follow us on Google News, Twitter, and LinkedIn.
About the Author
