MARCH 24: THE SCANNER MEANT TO CATCH THIS BECAME THE DELIVERY MECHANISM
LiteLLM is the open-source gateway a large share of the industry uses to route requests across OpenAI, Anthropic, and dozens of other model APIs through one interface — roughly 95 million downloads a month on PyPI, embedded deep enough in AI infrastructure that most engineering teams never think about it once it's wired in. On March 24, 2026, the threat-actor group tracked as TeamPCP didn't attack LiteLLM directly. It had already backdoored Trivy, the vulnerability scanner LiteLLM's own CI/CD pipeline ran on every build to check its code for exactly this kind of risk. When the poisoned scanner ran inside that pipeline, it handed TeamPCP the project's real PyPI publishing token — no phishing email, no typosquatted package, no separate breach to engineer. The attackers used LiteLLM's own credentials to ship malicious code from the actual, official, upstream project straight to everyone who upgraded.
A THREE-STAGE PAYLOAD, A FORTY-MINUTE WINDOW, A THREE-HOUR RESPONSE
Versions 1.82.7 and 1.82.8 carried a three-stage payload: a credential harvester sweeping SSH keys, cloud keys, Kubernetes secrets, cryptocurrency wallets, and .env files; a Kubernetes lateral-movement toolkit that deployed privileged pods to every node it could reach; and a persistent systemd backdoor to survive a reboot. The malicious versions were live on PyPI for roughly 40 minutes before LiteLLM's maintainer, Berri AI, caught them. Within three hours, Berri AI had pulled the releases, suspended new publishing, rotated its own credentials, brought in outside incident response, and told users to rotate "ALL credentials that were present as environment variables or config files on any system where litellm 1.82.7+ was installed." Judged by the usual pace of supply-chain incident response, that is fast, and Berri AI's public disclosure at the time was unusually direct about what had happened.
AUGUST 11: WHAT "CONTAINED" ACTUALLY LOOKED LIKE FIVE MONTHS ON
Speed at the source doesn't mean speed downstream. On August 11, CloudSEK published a reconstruction of who actually ran the backdoored versions during that 40-minute-to-three-hour window, built from exposed build logs, telemetry, and infrastructure fingerprints rather than from any list LiteLLM itself held. The number: more than 2,500 organizations and approximately 434,000 CI/CD pipelines "potentially exposed." CloudSEK was careful to caveat that a high-confidence match doesn't prove an organization was actually compromised or that stolen credentials were used against it — each one needs private validation. But the named high-confidence matches are not small or careless shops: Nvidia, AWS, Cisco, Salesforce, ServiceNow, Siemens, Samsung, S&P Global, Deloitte, Vodafone, BT, X Corp, and Zscaler, spanning technology, finance, telecommunications, manufacturing, consulting, and defense.
THE PART A PULLED PACKAGE CAN'T FIX
The FBI issued a FLASH advisory — FLASH-20260702-01 — on July 2, warning that credentials TeamPCP harvested during its campaign remained weaponizable long after the original intrusion window closed. That warning is the whole gap between "contained in three hours" and "still being mapped five months later" in one sentence. Berri AI's response fixed the hole at the source: the malicious code stopped being distributed, and anyone who rotated promptly closed their own exposure. What it could not do is un-steal credentials already harvested from thousands of other environments during that window, or tell each of those 2,500-plus organizations, individually, that they needed to go check. A vendor's fast fix and an enterprise's actual exposure are two different clocks, and CloudSEK's report is what happens when someone finally reads the second one five months late.
WHY A SCANNER WAS THE WEAK POINT, NOT THE PROTECTION
This wasn't an isolated hit on LiteLLM. The same TeamPCP campaign also backdoored Checkmarx's KICS scanner, and researchers tracking the combined campaign across Trivy, KICS, and LiteLLM put the total haul at over 300GB of compressed credentials and more than 500,000 corporate identities exposed. The pattern across both targets is the same: security tooling wired into CI/CD pipelines carries broad, trusted access by design, because it needs to see everything to scan everything. That makes a widely deployed scanner a higher-value target than most of the applications it's meant to protect — compromise one popular scanner once, and every pipeline that trusts it hands over its keys without anyone doing anything wrong on the receiving end.
WHAT THIS MEANS FOR TEAMS BUILDING ON AI
If your CI/CD pipeline ran LiteLLM 1.82.7 or 1.82.8, or ran Trivy at all, anytime around late March, don't treat a maintainer's public statement that an incident was "contained" as your own due diligence — that statement describes what the vendor fixed, not what already left your environment during the exposure window. Rotate the credentials independently and check your own build logs against the dates rather than waiting for your name to show up in someone else's report. And don't assume the absence of your name on CloudSEK's list means you're clear: CloudSEK itself says a match requires private validation to confirm, which means plenty of real exposure sits outside what's been publicly mapped so far. More broadly, this is a reminder that the tools sitting deepest in your AI supply chain — the gateways, the scanners, the CI dependencies nobody reviews line by line because they're "just infrastructure" — carry the most access and get the least scrutiny. If you're building production systems on top of open-source AI infrastructure and can't currently answer which of your dependencies could sign a release on your behalf if compromised, that's the audit worth running before the next CloudSEK report has your name on it.