A recently disclosed vulnerability in the open source AI gateway LiteLLM was exploited within days, according to security researchers. The flaw, tracked as CVE-2026-42208, carries a CVSS score of 9.3 and affects the proxy API key verification process. SecurityWeek reported that the issue can allow an attacker to read data from a LiteLLM proxy database and potentially modify it.

According to the available information, the weakness was first addressed in an April 20 advisory from LiteLLM’s maintainers and later indexed in the GitHub Advisory database on April 24. Sysdig then observed the first exploitation attempts about 36 hours after that indexing. The activity targeted database tables that contained sensitive information, including API keys, provider credentials, and environment variable configuration data.

How the vulnerability works

The flaw is described as an SQL injection issue in the proxy API key verification flow. LiteLLM’s maintainers said the database query used during key verification did not pass the caller-supplied value as a separate parameter. Instead, the value was included directly in the query. That coding mistake created the injection condition.

Sysdig noted that the call occurs before authentication is decided, which makes the issue fully pre-authenticated. In practical terms, any HTTP client that can reach the proxy port is enough to trigger the vulnerable path. An attacker could send a specially crafted Authorization header to an LLM API route and reach the query through the proxy’s error-handling path.

What attackers appeared to target

The exploitation observed by Sysdig was focused and specific. The attackers appeared to know LiteLLM’s Prisma-generated PostgreSQL identifier casing and used a column-count discovery sweep against each target table. The company said the activity was aimed at three tables holding sensitive information.

• API keys
• Provider credentials
• Proxy environment variable configuration

Sysdig said the observed requests were made 21 minutes apart, suggesting an automated tool may have been used. The same payload was reused while origin IP addresses were rotated. Despite the precision of the activity, no follow-on abuse was observed, and the extracted keys and credentials were not seen being used.

Impact and remediation

The main risk from the flaw is unauthorized access to database contents. Based on the source information, that includes the ability to read sensitive records and potentially modify them. The result could expose credentials stored in the LiteLLM proxy database.

The root cause has been identified in the advisory as a parameter-handling error in the query used during key verification. LiteLLM version 1.83.7 addresses the issue by ensuring that the caller-supplied value is always passed as a separate parameter.

Users are advised to update to the patched release as soon as possible. LiteLLM also recommended disabling error logs as a mitigation for the exploitation path.

Why the case stands out

Sysdig emphasized that the novelty of the finding was not a confirmed compromise, but rather the speed and precision of the attempted schema enumeration. The company described the activity as a textbook discovery sweep against the affected tables shortly after the advisory became public.

The case highlights how quickly attackers can move when a vulnerability is disclosed, especially when the issue affects authentication-adjacent logic and exposes sensitive backend data. In this instance, the attack surface existed before authentication was decided, which made the flaw accessible to any client that could reach the service.

For organizations running LiteLLM, the immediate priority is to verify they are on version 1.83.7 or later and to review whether the service exposed the vulnerable proxy path before patching.

In short, the LiteLLM flaw was quickly weaponized after disclosure, and while no confirmed abuse of the stolen data was observed, the potential for database exposure was serious enough to warrant immediate remediation.