Hackers Are Exploiting a Critical LiteLLM Pre-Auth SQL Injection Flaw

What happened

Active exploitation of a critical SQL injection vulnerability in LiteLLM, tracked as CVE-2026-42208, began approximately 36 hours after public disclosure on April 24, 2026, according to Sysdig researchers. The flaw affects LiteLLM’s proxy API key verification step and can be exploited without authentication by sending a specially crafted Authorization header to any LLM API route.

LiteLLM is a widely deployed open-source proxy and SDK middleware layer that allows developers to call multiple AI models through a single unified API. It stores API keys, virtual and master keys, and environment and configuration secrets, making its database a high-value target. The vulnerability allows unauthenticated attackers to read and modify data in that database, providing access to credentials for AI providers including OpenAI, Anthropic, and Amazon Bedrock.

Sysdig’s analysis of the exploitation activity shows a deliberate, two-phase attack pattern. In the first phase, attackers sent crafted requests to the /chat/completions endpoint with malicious Authorization headers to enumerate the database structure, querying only tables known to contain secrets and ignoring benign tables. In the second phase, attackers switched IP addresses for evasion and reran more precise payloads targeting the specific table names and structures identified in the first phase. Sysdig assessed the targeting as specific and deliberate, noting the attacker went straight to where the secrets live.

A fix is available in LiteLLM version 1.83.7, which replaces string concatenation with parameterized queries. For organizations that cannot upgrade immediately, the maintainers recommend setting disable_error_logs: true under general_settings as a workaround. LiteLLM was also recently targeted in a separate supply chain attack by TeamPCP, which released malicious PyPI packages designed to harvest credentials and tokens from infected systems.

Who is affected

Any organization running an internet-exposed LiteLLM instance below version 1.83.7 is directly vulnerable. Given LiteLLM’s role as an AI model gateway, a compromised instance exposes not just its own credentials but the API keys and provider credentials for every AI service it proxies, potentially including OpenAI, Anthropic, and Bedrock environments.

Why CISOs should care

LiteLLM sits at the center of AI development infrastructure for a growing number of organizations, and its database contains the keys to every AI provider connection it manages. A pre-authentication SQL injection that reaches those credentials in a targeted, two-phase attack within 36 hours of disclosure is a narrow window that many patching cycles are not designed to close in time.

The combination of the CVE exploitation and the earlier TeamPCP supply chain attack on LiteLLM’s PyPI packages means this tool has now been targeted through two distinct attack vectors in quick succession. Organizations running LiteLLM in production should treat it as an actively targeted component of their AI infrastructure, not a peripheral development tool.

3 practical actions

1. Upgrade to LiteLLM version 1.83.7 immediately and treat any internet-exposed instance running a prior version as potentially compromised: The 36-hour exploitation window means vulnerable instances that were publicly accessible after April 24 should be assumed to have been targeted. Rotate all virtual API keys, master keys, and provider credentials stored in those instances regardless of whether exploitation has been confirmed.
2. Restrict internet exposure of LiteLLM instances to authorized networks only: An AI model gateway with access to production provider credentials has no business being accessible from the public internet without strict network-level controls. Review whether your LiteLLM deployment is internet-facing and apply IP allowlisting or VPN-only access as an immediate risk reduction measure.
3. Apply the disable_error_logs workaround if immediate patching is not possible: Setting disable_error_logs: true under general_settings blocks the path through which malicious inputs reach the vulnerable query. This is a temporary measure and does not replace upgrading to 1.83.7, but it reduces exploitation risk for organizations that cannot patch immediately.