LiteLLM exploited within 36 hours of disclosure via SQL injection bug

For the second time in five weeks, BerriAI’s LiteLLM Python package was exploited in the wild, this time within 36 hours of disclosure.

In the latest exploit, a critical SQL injection bug — CVE-2026-42208 — could let an attacker read data from the proxy’s database and modify it, leading to unauthorized access to the proxy and the credential it manages.

The maintainers said if it’s not possible to immediately upgrade, teams should set disable_error_logs: true under general_settings, which will  remove the path through which unauthenticated input reaches the vulnerable query.

Jacob Krell, senior director, secure AI solutions and cybersecurity at Suzu Labs, explained that the TeamPCP campaign backdoored the package in March through a supply chain compromise tied to the release pipeline. This time, Krell said attackers exploited a pre-auth SQL injection to extract secrets directly from the application database: different route, same destination.

“LiteLLM sits in a position of concentrated trust,” said Krell. “It brokers access to OpenAI, Anthropic, Bedrock, and other AI providers, which means it holds API keys, provider credentials, routing configurations, and secrets far more valuable than the application itself. Any component that centralizes that much authority needs to be assessed like a secrets manager or certificate authority, not like an ordinary open source dependency.”

Michael Clark, senior director of threat research at Sysdig, which posted an April 27 blog on the topic, said that the speed we saw in the 36-hour exploitation of LiteLLM underscores a trend we’re seeing across the board: the gap between disclosure and abuse has compressed exponentially.

“In 2025, it took threat actors an average of 23 days to exploit vulnerabilities,” said Clark. “Today, we’re measuring in hours. AI is enabling vulnerability analysis and weaponization that weren’t possible before.”

Clark added that the LiteLLM case stands out for its precision. The March 2026 supply chain incident was opportunistic: a malicious package harvesting whatever credentials it could access. In the April vulnerability, the SQL injection targeted specific, high-value data tied to AI control planes, indicating prior knowledge of both data location and access paths.

“It shows the value AI can provide in accelerating processes, where it can work through details at machine speed,” said Clark. “For defenders, the takeaway is straightforward: patching vulnerabilities alone won’t help you keep up. Effective defense now depends on runtime visibility and the ability to detect and disrupt abuse in real time, especially for identity and secrets.”

Harold Byun, chief product officer at BlueRock, said in the March supply chain case, the risk came from malicious code being introduced upstream and executed with full trust. Now, Byun, who wrote an SC Media Perspectives last week on the first case, said we’re looking at a straightforward vulnerability, but with the same level of access and impact.

“That’s the shift,” said Byun. “It’s not just how code gets in, it’s what these components are connected to once they’re running and the execution layer. LiteLLM sits between models, credentials, and downstream execution, so even a basic flaw like SQL injection can expose keys, modify state, and open paths into broader infrastructure.”

Byun said the speed also matters. Exploitation can happen now within hours, not days, and Byun said AI has compressed that window even further by accelerating both discovery and targeting.

“When you combine high-trust placement with collapsing time to exploit, scan-and-patch alone won’t keep up,” said Byun. “Organizations need to assume compromise and focus on active security to control behavior once these systems are live."

Itai Goldman, co-founder and CTO of Miggo Security, added that the earlier LiteLLM incident was a supply chain compromise: attackers poisoned a trusted package and waited for organizations to install it.

Goldman said CVE-2026-42208 is much more direct: if a vulnerable LiteLLM proxy is reachable, the attacker can target the gateway itself without credentials and without compromising the package ecosystem first. What makes this particularly dangerous, said Goldman, is that the vulnerability impacts the default configuration, and even when companies attempt to protect their instances, this specific API endpoint is usually left exposed.

“That distinction matters because LiteLLM is not just another application,” said Goldman. “It’s often the broker between enterprise applications and model providers like OpenAI, Anthropic, Bedrock, and Vertex. It holds provider keys, routing logic, and crucially, the actual prompts and responses. When this layer falls, the blast radius extends far beyond credential theft — it opens the door to the massive exposure of highly-sensitive company IP and private employee data contained within those prompts.”

Hanah-Marie Darley, chief AI officer and co-founder of Geordie AI, said while the speed from disclosure to exploitation isn’t new, what’s changed is how targeted the exploitation has become.

“In this case, the activity wasn’t broad scanning,” said Darley. “It showed a clear understanding of how LiteLLM is structured and went straight after API keys and provider credentials. That’s consistent with what we saw earlier this year in the LiteLLM supply chain incident. So this isn’t about speed increasing. It’s about exploitation becoming more precise and more accessible. That’s what’s compressing the window in a way that matters.”