Hackers are exploiting a critical LiteLLM pre-auth SQLi flaw
Source: Bleeping Computer
Hackers are targeting sensitive information stored in the LiteLLM open‑source large‑language model (LLM) gateway by exploiting a critical vulnerability tracked as CVE‑2026‑42208.
The flaw is an SQL injection issue that occurs during LiteLLM’s proxy API key verification step. An attacker can exploit it without authentication by sending a specially crafted Authorization header to any LLM API route. This allows reading data from the proxy’s database and modifying it. According to the maintainer’s security advisory, threat actors could use it for “unauthorised access to the proxy and the credentials it manages.”
A fix was delivered in LiteLLM version 1.83.7, which replaces string concatenation with parameterized queries.
LiteLLM stores API keys, virtual and master keys, and environment/config secrets, so accessing its database allows hackers to read sensitive data they may then use to launch additional attacks.
LiteLLM is a popular proxy/SDK middleware layer that enables users to call AI models via a single unified API. The project is widely used by developers of LLM apps and platforms managing multiple models. It has 45 k stars and 7.6 k forks on GitHub.
The project has also recently been targeted in a supply‑chain attack, where TeamPCP hackers released malicious PyPI packages that deployed an infostealer to harvest credentials, tokens, and secrets from infected systems.
In a report from researchers at Sysdig, a cloud security company, exploitation of CVE‑2026‑42208 started approximately 36 hours after the bug was disclosed publicly on April 24.
Active exploitation activity
The researchers observed deliberate and targeted exploitation attempts that sent crafted requests to /chat/completions with a malicious Authorization: Bearer header. These requests queried specific tables that contained API keys, provider (OpenAI, Anthropic, Bedrock) credentials, environment data, and configs.
Sysdig explained that there were no probes against benign tables, and “the operator went straight to where the secrets live,” a strong indicator that the attacker knew exactly what to target.
In the second phase of the attack, the threat actor switched IP addresses—likely for evasion—reran the same SQL injection attempts, but focused on the correct table names and structures derived in the previous phase, now using fewer, more precise payloads.
Sysdig noted that, while 36 hours is not as quick as exploiting a recent flaw in Marimo, the attacks were targeted and specific.
The researchers warned that exposed LiteLLM instances still running vulnerable versions should be treated as potentially compromised, and every virtual API key, master key, and provider credential stored in internet‑exposed LiteLLM instances should be rotated.
For those who can’t upgrade to LiteLLM 1.83.7 or later, the maintainers suggest the workaround of setting:
general_settings:
disable_error_logs: trueto block the path through which malicious inputs can reach the vulnerable query.