CVE-2026-42208 began being actively exploited roughly 36 hours after the bug was disclosed publicly on April 24, according to researchers at Sysdig.
How CVE-2026-42208 works inside LiteLLM
The vulnerability is a pre-authentication SQL injection that triggers during LiteLLM’s proxy API key verification step. An attacker can exploit the flaw without authentication by sending a specially crafted Authorization header to any LLM API route. The LiteLLM maintainers warned that threat actors could use the flaw for "unauthorised access to the proxy and the credentials it manages." The patch in LiteLLM version 1.83.7 replaces vulnerable string concatenation with parameterized queries to close the injection vector.
Active exploitation observed by Sysdig researchers
Sysdig’s report describes deliberate, targeted exploitation attempts that began approximately 36 hours after public disclosure. The attackers sent crafted requests to the '/chat/completions' endpoint with a malicious 'Authorization: Bearer' header. In an initial phase the actor probed tables and in a follow-up phase switched IP addresses—likely for evasion—and reran SQLi attempts focused on the correct table names, using fewer and more precise payloads. Sysdig noted that "the operator went straight to where the secrets live," observing that there were no probes against benign tables, which it read as a strong indicator the attacker knew what to target.
What the attackers sought: API keys, provider credentials, and secrets
LiteLLM instances store a wide variety of credentials and configuration data. The exploitation attempts specifically queried tables that contained API keys, virtual and master keys, provider credentials for OpenAI, Anthropic, and Bedrock, environment data, and configuration entries. Because the flaw allows both reading and modifying the proxy’s database, attackers gaining access can extract sensitive data and also alter what the proxy presents or authorizes—escalating risk for follow-on attacks.
Patch, workaround, and operational remediation
LiteLLM maintainers released a fix in version 1.83.7 that replaces string concatenation with parameterized queries. For instances that cannot immediately upgrade, the maintainers recommend a configuration workaround: set 'disable_error_logs: true' under 'general_settings' to block the path through which malicious inputs can reach the vulnerable query. Sysdig cautions that exposed LiteLLM instances still running vulnerable versions should be treated as potentially compromised and that "every virtual API key, master key, and provider credential stored in internet-exposed LiteLLM instances should be rotated."
Supply-chain context: TeamPCP PyPI packages and broader credential risk
The LiteLLM project has also been targeted in a recent supply-chain incident: TeamPCP hackers released malicious PyPI packages that deployed an infostealer to harvest credentials, tokens, and secrets from infected systems. That prior activity amplifies the risk from CVE-2026-42208 because credentials harvested from compromised developer or CI environments could be used alongside database exfiltration to widen access across infrastructure and downstream services.
What LiteLLM maintainers, instance operators, and developers should do
- LiteLLM maintainers: ensure the patch (v1.83.7) is distributed, documented, and promoted to users relying on internet-exposed proxies; continue to advise on safe configuration and key-rotation practices.
- Instance operators and platform teams running internet-exposed LiteLLM: upgrade to 1.83.7 immediately or apply the 'disable_error_logs: true' workaround if an immediate upgrade is impossible; assume susceptible instances may already be compromised and rotate every virtual API key, master key, and provider credential stored in those instances.
- Developers and CI teams: audit local and pipeline environments for signs of the previously reported TeamPCP PyPI infostealer and verify that credentials stored or cached by development tooling were not exfiltrated.
The rapid, focused nature of these attacks underscores two facts in the record: attackers weaponized knowledge of where LiteLLM keeps secrets, and defenders have a short window to act. For any internet-facing LiteLLM deployment, the safe path is immediate patching or the documented workaround, accompanied by comprehensive credential rotation and post-compromise assumptions until evidence shows otherwise.
Original reporting: Hackers are exploiting a critical LiteLLM pre-auth SQLi flaw — BleepingComputer
