Researchers this month recovered a 153GB archive of stolen credentials tied to 2,488 companies — AWS keys, Salesforce client secrets, Slack signing secrets, Azure environment variables, LLM provider keys, all pulled from 118,829 CI runner dumps across 433,909 files. The trail leads back to one project: LiteLLM, the open-source gateway that sits in front of OpenAI, Anthropic, and AWS Bedrock for an estimated 95 million downloads a month, and centralizes exactly the kind of credentials that just leaked.
It's tempting to read this as a story about one badly-run project. LiteLLM's own CVE history doesn't help that impression: a blind SQL injection in the /team/update endpoint in 2024 (CVE-2024-4890), a file-read SQL injection via /key/block in 2025 (CVE-2025-45809), and a pre-auth SQL injection so severe — CVSS 9.3, exploitable with nothing but a crafted Authorization header — that CISA added it to its Known Exploited Vulnerabilities catalog within three weeks of disclosure in April 2026 (CVE-2026-42208). A month after that, a three-bug chain let any low-privilege user promote themselves to admin and execute code on the server (CVE-2026-47101, CVE-2026-47102, and a sandbox escape, combined CVSS 9.9). Three SQL injections in three years, in the tool holding everyone's API keys, is a legitimately bad track record.
But the 153GB dump didn't come from any of those bugs. It came from somewhere more uncomfortable.
The scanner that opened the door
In March 2026, a threat actor tracked as TeamPCP compromised Trivy — a widely-used, unrelated open-source vulnerability scanner — and used stolen credentials to publish a poisoned release. LiteLLM's own CI pipeline, like thousands of others, pulled that release automatically as part of routine dependency scanning. That gave the attackers a foothold inside LiteLLM's build environment, which they used to publish two backdoored LiteLLM releases — versions 1.82.7 and 1.82.8 — to PyPI on March 24.
Every organization that installed one of those two versions, even briefly, had its own CI environment swept: SSH keys, cloud credentials, Kubernetes tokens, .env files, LLM API keys, whatever the pipeline could see. That's where Amazon, Cisco, Microsoft, Nvidia, and Salesforce's secrets came from — not a bug in LiteLLM's code, but a bug in a tool LiteLLM trusted, which downstream teams then trusted by extension without knowing it.
Why "just patch faster" isn't the lesson
It's easy to look at CVE-2026-42208's 36-hour window from disclosure to active exploitation and conclude the fix is patching speed. Patching speed matters, and CISA's own KEV deadline (three days for federal agencies) is the right instinct. But the supply-chain leg of this story didn't involve a known CVE at all. There was nothing to patch, because nothing LiteLLM's maintainers wrote was vulnerable — the vulnerability was in the trust relationship between LiteLLM's CI and a scanner it never audited, running with permissions it never questioned.
That's the actual pattern worth sitting with: an AI gateway is valuable precisely because it centralizes credentials — one place to hold every provider key instead of scattering them across a hundred services. That's also exactly what makes it a catastrophic single point of failure the moment anything upstream of it is compromised, whether that's LiteLLM's own code or a dependency three hops removed that almost nobody on the security team has ever heard of. The industry adopted these gateways at 95-million-downloads-a-month speed. The operational discipline around what they're allowed to trust, and what happens when that trust is misplaced, hasn't caught up at the same pace.
Drawn the way a threat-modeling review would actually draw it — as a data flow diagram with explicit trust boundaries, the notation AWS and Microsoft both use in their own security guidance — the failure point stops being abstract:
What actually reduces the blast radius here
None of the following would have stopped the Trivy compromise. All of them shrink what it costs you when the next one happens, because there will be a next one — this exact pattern (compromise a popular tool, ride its CI privileges into downstream projects) has hit xz, various npm packages, and now Trivy and LiteLLM, and it will hit something else next year.
- Scope gateway keys per team, not globally. A single master key that reaches every provider is a single point of failure by design. Split it, and a compromised key costs you one team's blast radius, not the whole org's.
- Treat CI as a credential store, because it is one. Anything your pipeline can read, an attacker who compromises any tool your pipeline runs can read too. Audit what secrets your CI actually needs versus what it happens to have access to.
- Pin and review your scanners, not just your application dependencies. Trivy is exactly the kind of tool teams auto-update without a second thought, because it's "just" a security scanner. That reflex is precisely what made it a useful attack vector.
- Rotate on disclosure, not on schedule. If you ran LiteLLM 1.82.7 or 1.82.8 even briefly in March, every credential your CI could see should already be rotated — waiting for a quarterly rotation cycle isn't sufficient once you know a window like this existed.
The uncomfortable version of "how broken do you have to be to keep running this" is that most teams running LiteLLM weren't being reckless — they were doing what the entire industry is currently doing with AI tooling: adopting fast, centralizing credentials for convenience, and trusting the dependency graph underneath it more than they'd ever admit if asked directly. That's not a LiteLLM-shaped problem. It's the shape of this whole moment in AI infrastructure, and it's the same principle we build every NovuSpark security session around — the tooling changes every quarter; the discipline of knowing exactly what you're trusting, and why, doesn't.