CVE-2026-42208: Critical Pre-Auth SQL Injection in LiteLLM Actively Exploited Within 36 Hours of Disclosure

CVE-2026-42208: Critical Pre-Auth SQL Injection in LiteLLM Actively Exploited Within 36 Hours of Disclosure

Executive Summary

CVE-2026-42208 is a critical pre-authentication SQL injection vulnerability affecting LiteLLM, an open-source large language model (LLM) gateway that proxies requests to providers such as OpenAI, Anthropic, and others. Within 36 hours of public disclosure, this vulnerability was actively exploited in the wild, with attackers targeting sensitive backend data including API keys and provider credentials. The vulnerability arises from improper handling of the HTTP Authorization header, allowing remote attackers to inject arbitrary SQL into the backend PostgreSQL database. This advisory provides a comprehensive technical analysis, threat actor profile, exploitation timeline, victimology, and actionable mitigation strategies.

Threat Actor Profile

The exploitation of CVE-2026-42208 was characterized by targeted, non-automated activity. The threat actors demonstrated a high degree of technical proficiency, evidenced by their precise schema enumeration and the use of correct PascalCase table names, suggesting prior reconnaissance or the use of advanced tooling such as LLMs for code analysis. The attackers operated from IP addresses registered to 3xK Tech GmbH in Germany, specifically 65.111.27.132 and 65.111.25.67. Their methodology did not match the patterns of commodity botnets or mass exploitation campaigns; instead, it reflected a focused effort to extract high-value secrets from vulnerable LiteLLM deployments. No attribution to a known advanced persistent threat (APT) group has been established as of this report, but the sophistication and speed of exploitation indicate a threat actor with significant expertise in SQL injection and cloud infrastructure targeting.

Technical Analysis of Malware/TTPs

The core of CVE-2026-42208 lies in the authentication logic of LiteLLM, where the value of the Authorization: Bearer header is concatenated directly into a SQL query without parameterization or sanitization. This design flaw enables attackers to craft malicious Bearer tokens that inject arbitrary SQL statements into the backend PostgreSQL database. The attack is fully pre-authentication, meaning no valid credentials are required to exploit the flaw.

A typical exploit request observed in the wild is as follows:

POST /chat/completionsAuthorization: Bearer sk-litellm' UNION SELECT api_key,NULL,NULL,NULL,NULL FROM litellm_verificationtoken--User-Agent: Python/3.12 aiohttp/3.9.1

The attackers targeted three primary tables: LiteLLM_VerificationToken (containing virtual API keys and master keys), litellm_credentials (storing provider credentials), and litellm_config (holding proxy environment variables). The exploitation process involved schema enumeration using multiple UNION SELECT payloads, adjusting for table name casing and column count to match the backend query structure. The attackers also employed tautological queries such as OR 1=1-- to bypass authentication logic and maximize data extraction.

The observed user-agent string was consistently Python/3.12 aiohttp/3.9.1, and the attack vector was exclusively via HTTP POST requests to /chat/completions or /v1/chat/completions endpoints. The payloads were carefully crafted, indicating manual testing and refinement rather than automated scanning.

Exploitation in the Wild

Exploitation of CVE-2026-42208 began within 36 hours of public disclosure. The initial advisory was published on the LiteLLM repository security tab on April 20, 2026, and indexed in the GitHub Advisory Database on April 24, 2026. The first exploitation attempt was observed on April 26, 2026, at 04:24 UTC from IP address 65.111.27.132. The attackers conducted a schema enumeration phase, sending 17 UNION SELECT payloads targeting three specific tables. Shortly thereafter, a second IP address (65.111.25.67) replayed and refined the payloads, probing key management APIs and further adjusting the attack vectors.

The exploitation was characterized by deliberate, non-generic payloads, with attackers demonstrating knowledge of the internal schema and adjusting their queries to match the backend structure. No evidence of successful credential reuse or monetization was observed by security researchers at Sysdig, but the targeting was precise and indicative of a skilled operator.

Victimology and Targeting

The primary targets of this exploitation campaign were organizations running vulnerable versions of LiteLLM (versions >= 1.81.16 and < 1.83.7) exposed to the public internet. The attackers focused on extracting API keys, master keys, and provider credentials, which could be leveraged for further attacks against downstream AI services or cloud infrastructure. The exploitation did not appear to be opportunistic; rather, it was targeted at high-value assets within organizations leveraging LiteLLM as an AI gateway. There is no evidence of widespread mass exploitation or indiscriminate scanning, suggesting that the attackers prioritized stealth and precision over volume.

Mitigation and Countermeasures

Immediate action is required to mitigate the risk posed by CVE-2026-42208. Organizations should upgrade LiteLLM to version 1.83.7 or later, as this release includes the necessary patch to address the SQL injection vulnerability. All API keys, master keys, and provider credentials stored in any LiteLLM instance exposed during the vulnerable window should be rotated without delay. Security teams should audit logs for Authorization headers containing single quotes or SQL keywords, and specifically look for requests originating from the identified IOCs (65.111.27.132 and 65.111.25.67) or using the user-agent Python/3.12 aiohttp/3.9.1.

To further reduce exposure, organizations should remove direct internet access to LiteLLM proxies, instead placing them behind internal networks or authenticated reverse proxies. Continuous monitoring for unusual traffic to /chat/completions endpoints and for anomalies in provider billing is recommended to detect potential abuse. Implementing strict input validation and parameterized queries in all custom integrations is essential to prevent similar vulnerabilities in the future.

References

About Rescana

Rescana is a leader in third-party risk management (TPRM), providing organizations with a comprehensive platform to continuously monitor, assess, and mitigate cyber risks across their digital supply chain. Our advanced threat intelligence and automation capabilities empower security teams to proactively identify vulnerabilities, respond to emerging threats, and ensure compliance with industry standards. For questions or further assistance, we are happy to help at ops@rescana.com.