On April 24, 2026, the critical SQL injection vulnerability CVE-2026-42208 affecting the open-source AI gateway LiteLLM was disclosed in the GitHub Advisory Database. Just 36 hours and 7 minutes after disclosure, real-world exploitation was already observed. Rated CVSS 9.3 (Critical), this vulnerability requires no authentication. By sending a specially crafted Authorization: Bearer header to common API endpoints such as /chat/completions, attackers can execute arbitrary SQL queries against the PostgreSQL database used by the LiteLLM proxy. That database often contains centralized credentials for cloud AI providers including OpenAI, Anthropic, and AWS Bedrock.
Security researchers described the impact as “closer to full cloud account compromise than a typical web application SQL injection.” This article analyzes the technical root cause of CVE-2026-42208, the attack flow, and how AI infrastructure is creating entirely new attack surfaces.
CVE-2026-42208: LiteLLM SQL Injection Vulnerability Overview
| Category | Description |
|---|---|
| Vulnerability ID | CVE-2026-42208 |
| Affected Product | BerriAI LiteLLM Python Package |
| Vulnerability Type | SQL Injection |
| CVSS Score | 9.3 (Critical) |
| Affected Versions | 1.81.16 through 1.83.6 |
| Patch Version | 1.83.7-stable (Released April 19, 2026) |
| Exploitation Status | First attack observed 36 hours and 7 minutes after public disclosure |
LiteLLM is an open-source AI gateway with over 45,000 GitHub stars and 7,600 forks, widely used by developers and enterprises to integrate more than 100 LLM providers, including OpenAI, Anthropic, AWS Bedrock, and Gemini, through a single OpenAI-compatible API. Because of this architecture, LiteLLM effectively becomes a centralized repository for organizational AI credentials.
Technical Root Cause: Missing parameter binding in the error-handling path
The vulnerability occurs during the API key verification process within the LiteLLM proxy.
When a user calls an LLM API endpoint (e.g., POST /chat/completions), the proxy extracts the API key from the Authorization: Bearer header and queries the LiteLLM_VerificationToken table. In a secure implementation, the key value should be passed separately as a SQL parameter. However, in affected versions, the Bearer value was inserted directly into the SQL query string. Critically, this vulnerable query path is triggered not only during normal authentication but also through the error-handling logic. This means that even invalid tokens can reach the vulnerable query execution path.
By inserting a single quote into the Bearer value, attackers can break out of the SQL query and use UNION SELECT statements to query arbitrary database tables. Since the injection occurs before authentication is completed, any HTTP client capable of reaching the proxy port (default: 4000) can exploit the vulnerability without additional requirements.
The Three Tables Targeted by Attackers
Observed attacks were not random scans. Attackers demonstrated prior knowledge of Prisma ORM’s PostgreSQL identifier casing used internally by LiteLLM and precisely targeted only three high-value tables.
1. LiteLLM_VerificationToken
This table stores virtual API keys and master keys. Stolen keys can immediately be reused against endpoints such as /chat/completions, and LiteLLM does not bind keys to specific source IPs by default.
2. LiteLLM_credentials
This was the highest-value target. It stores upstream LLM provider credentials, including:
- OpenAI organization keys
- Anthropic workspace administrator keys
- AWS Bedrock IAM credentials
In many cases, a single row contains credentials for multiple providers simultaneously.
3. LiteLLM_config
This table stores proxy runtime environment variables and internal configurations, enabling attackers to understand the entire proxy operating environment. Notably, user-related tables such as litellm_users or litellm_team were not targeted. This indicates that the attackers’ primary objective from the beginning was AI provider credentials.
36 Hours: The Advisory Alone Was Enough
One of the most notable aspects of this incident was the combination of speed and precision. The patch itself had already been released on April 19, 2026. The advisory was indexed into the GitHub Global Advisory Database on April 24 at 16:17 UTC, and the first attack was observed only 36 hours and 7 minutes later, on April 26. Attackers reproduced the exploit using only the advisory information and the open-source schema, without waiting for a public PoC release. Because LiteLLM is open source, the database schema was accessible directly from the codebase, allowing attackers to map the table structure in advance.
A Repeated Pattern of Attacks Targeting LiteLLM
CVE-2026-42208 marks the second major security incident targeting LiteLLM. Just one month earlier, in March 2026, the hacking group TeamPCP conducted a supply chain attack by distributing malicious PyPI packages through LiteLLM’s release pipeline, stealing credentials and secrets from downstream users. The March attack compromised trusted packages to collect credentials from installed systems, while CVE-2026-42208 directly extracted credentials from vulnerable LiteLLM proxy databases. Although the methods differed, the objective was the same:
Cloud provider credentials managed by AI gateways.
Internet-Exposed LiteLLM Instances Observed via Criminal IP
Following the disclosure of CVE-2026-42208, Criminal IP was used to identify internet-exposed LiteLLM-related assets and analyze the current exposure landscape.
Criminal IP Search Query: title: LiteLLM
LiteLLM exposes its service name directly in the page title of its web interface, making it possible to identify externally accessible instances using simple HTML title–based searches. Unlike network appliances or traditional web management consoles that are intentionally designed for internet exposure, LiteLLM functions more like an internal AI infrastructure component. As a result, every instance identified through Criminal IP can be considered a misconfiguration in itself, an AI gateway exposed to the public internet without private network segmentation or VPN protection.
Based on this query, more than 2,000 exposed assets were identified as of April 2026. These are not merely misconfigured systems, but AI gateway proxies that centrally manage sensitive organizational cloud credentials, including API keys for upstream LLM providers such as OpenAI, Anthropic, and AWS Bedrock. In the context of CVE-2026-42208, these instances can become immediately exploitable targets without authentication.
Criminal IP Search Query: title: LiteLLM AND port: 4000
LiteLLM proxies run on port 4000 by default. Since this is not a common public web service port, LiteLLM instances discovered on this port strongly suggest unintended internet exposure. In particular, instances running on the default port may indicate development or testing environments that were exposed directly to the internet without sufficient security hardening.
Filtering for LiteLLM instances operating on the default port identified 28 exposed assets at the time of writing. Although smaller in number compared to the overall exposure count, these environments are considered especially critical because they appear to be running with near-default configurations. Given that CVE-2026-42208 was exploited in the wild within just 36 hours of disclosure, such default deployments may represent the easiest entry points for attackers.
Detailed analysis of a specific LiteLLM asset detected by Criminal IP revealed that HTTPS (443) was externally accessible. Additionally, four associated vulnerabilities and one Exploit DB reference were identified, indicating that the environment is not simply an exposed web service, but one potentially connected to already known attack techniques. This asset is not a network appliance or firewall intentionally designed for public exposure, it is an AI gateway proxy capable of storing upstream LLM provider credentials, directly exposed to the internet.
If a SQL injection attack succeeds against such an environment, the impact extends far beyond a typical web application compromise. As Sysdig noted, a single row in the LiteLLM database may contain OpenAI organization keys with monthly usage limits worth tens of thousands of dollars, Anthropic workspace administrator keys, and AWS Bedrock IAM credentials simultaneously. As a result, successful exploitation may lead not only to data leakage, but effectively to compromise of entire cloud accounts.
In conclusion, the more than 2,000 publicly exposed LiteLLM instances identified through Criminal IP represent an extremely high-risk attack surface. This is not only because CVE-2026-42208 can be exploited immediately without authentication, but because the very existence of LiteLLM instances on the public internet constitutes a severe misconfiguration that exposes an organization’s entire AI infrastructure.
Mitigation and Recommendations
CVE-2026-42208 was fixed in LiteLLM 1.83.7. The official LiteLLM advisory identifies affected versions as 1.81.16 through versions prior to 1.83.7, and recommends upgrading to 1.83.7 or later. LiteLLM additionally recommends updating to the latest stable release, 1.83.10-stable.
Organizations should prioritize the following actions:
- Upgrade LiteLLM Proxy to 1.83.7 or later, preferably 1.83.10-stable
- Identify externally accessible LiteLLM Proxy assets
- Restrict external access to LLM API routes such as
/chat/completions - Review LiteLLM database access logs and PostgreSQL query history
- Check for abnormal access patterns involving
litellm_credentialsandlitellm_config - Rotate LLM provider API keys, virtual API keys, and cloud credentials
- Investigate communication logs involving suspicious IP addresses
If a LiteLLM Proxy was directly accessible from the internet, patching alone is insufficient. Organizations must assume that attackers may already have queried the database and should therefore treat all stored provider credentials and API keys as compromised and rotate them immediately.
FAQ
Q1. Why is CVE-2026-42208 considered so dangerous?
This vulnerability is a pre-authentication SQL injection issue. Attackers can manipulate the API key verification process of the LiteLLM Proxy simply by sending a crafted Authorization header, without requiring a valid API key. Because LiteLLM centrally manages multiple LLM provider keys and cloud AI service credentials, compromising the database can directly lead to compromise of upstream provider accounts.
Q2. How is this attack different from traditional SQL injection attacks?
The observed attacks were not indiscriminate automated scans using tools such as SQLmap. Attackers already understood the internal LiteLLM database schema and precisely targeted only three tables containing AI credentials out of dozens of available tables. This case demonstrates how attacks against open-source AI infrastructure are becoming increasingly precise and objective-driven. Attackers reproduced the exploit using only the advisory and open-source codebase, before any public PoC was released.
Conclusion
CVE-2026-42208 represents a major wake-up call for AI infrastructure security. Within just two months, LiteLLM became the target of both a supply chain attack and a direct SQL injection attack. The attack vectors differed, but the objective remained consistent as cloud credentials managed by AI gateways. This incident highlights two critical lessons. First, AI gateways are no longer merely developer convenience tools. They function as centralized credential repositories connected to an organization’s entire AI infrastructure and therefore require security standards equivalent to those applied to secret management systems. Second, the 36-hour exploitation window demonstrates that traditional patch timelines measured in days are no longer sufficient. Identifying where externally exposed LiteLLM instances exist and immediately determining whether vulnerable versions are running must take priority even before patch deployment itself.
In relation to this, you can refer to CVE-2024-53900 & CVE-2025-23061 RCE Vulnerabilities in Mongoose: Security Threats Exposure and Countermeasures
You can subscribe to Criminal IP (criminalip.io/register) and start detecting vulnerable assets right away. You can also request a demo using the button below and explore Criminal IP’s threat intelligence (TI) analysis of externally exposed assets at the enterprise level.
This report is based on data from Criminal IP, a Cyber Threat Intelligence search engine. Sign up for a free Criminal IP account today to explore the search results mentioned in the report and delve into comprehensive threat intelligence.
Source: Criminal IP(https://www.criminalip.io), SECURITYWEEK (https://www.securityweek.com/fresh-litellm-vulnerability-exploited-shortly-after-disclosure/), SecurityAffairs (https://securityaffairs.com/191483/hacking/cve-2026-42208-litellm-bug-exploited-36-hours-after-its-disclosure.html), TheHackerNews (https://thehackernews.com/2026/04/litellm-cve-2026-42208-sql-injection.html)
Related article: https://www.criminalip.io/knowledge-hub/blog/26457