The scanner that was supposed to catch this
The irony sits at the center of this breach: the entry point was Trivy, the open-source security scanner that LiteLLM's own build pipeline relied on to catch exactly this kind of tampering. Attackers, tracked by Google under the identifier UNC6780 and operating as what CloudSEK calls the TeamPCP campaign, got into Trivy through a leaked automation token. That token had been rotated at some point after exposure, but the rotation was incomplete, and the old credential kept working. The attackers sat inside the pipeline for roughly 20 days before using that access to push malicious code.
On March 24, 2026 at 10:39 UTC, two tampered releases, versions 1.82.7 and 1.82.8, went live on PyPI. They were pulled about 40 minutes later, but PyPI's own guidance is to treat any install that happened through 16:00 UTC that day as suspect, since caching and mirror propagation extend the real exposure window well past the moment the malicious files were removed from the primary index. Forty minutes was enough time for the packages to reach a large fraction of the automated build systems that pull LiteLLM as a dependency in AI application pipelines.
How the payload evaded detection
The malicious code shipped inside a file called litellm_init.pth. Files with a .pth extension are a legacy Python packaging mechanism that gets executed automatically the moment the interpreter starts, before any application code runs and before most runtime security tooling has a chance to inspect what is executing. That makes it a favored technique for supply-chain attackers precisely because most container image scanning and dependency vetting happens at install time, looking at package metadata and known-malware signatures, not at what fires the first time Python boots inside a freshly built image.
Once running, the payload harvested cloud provider keys for AWS, GCP and Azure, Kubernetes service account tokens, database passwords, SSH keys and environment variables, explicitly including OPENAI_API_KEY and ANTHROPIC_API_KEY values that sit in the environment of nearly every AI application built on top of LiteLLM's gateway. That detail matters: LiteLLM sits at the exact point in an AI stack where API keys for every downstream model provider converge, which made it a disproportionately valuable target relative to a typical utility library. Exfiltrated data went to the attacker-controlled domain models.litellm[.]cloud.
The scale, and the caveat on the numbers
CloudSEK's investigation maps roughly 434,000 captured files back to more than 2,500 organizations, with high-confidence exposure matches including NVIDIA, Cisco Systems, Deloitte, Volkswagen, FedEx, Siemens and X Corp. Those are exfiltrated files and events, not confirmed compromised accounts, so the real number of organizations with material impact could run lower once each company completes its own forensic review. Even taken conservatively, this is one of the largest AI-infrastructure supply-chain incidents disclosed in 2026, both in raw scale and in the sensitivity of what a LiteLLM deployment typically has access to.
The FBI issued a FLASH advisory, FLASH-20260702-01, in early July warning that the stolen credentials could be weaponized for follow-on access, months after the original compromise but well ahead of CloudSEK's public disclosure in August. That five-month gap between the incident and public reporting is itself a data point worth internalizing: a supply-chain compromise can sit undetected in a widely used dependency for a long stretch before either the vendor or a third-party researcher surfaces it, which is exactly the argument for continuous SBOM monitoring rather than point-in-time vetting.
Why LiteLLM specifically was a target worth this effort
LiteLLM functions as a unified gateway that lets engineering teams call OpenAI, Anthropic, Google and dozens of other model providers through one interface, which means a huge fraction of enterprise AI deployments route every model API call through it. Compromising that chokepoint gives an attacker visibility into which AI providers an organization uses, what those API keys can access, and often a foothold inside the CI/CD pipeline that builds and deploys the AI application itself. That is a far more valuable target than a generic utility package, and it reflects a broader shift where the AI tooling layer, not just the AI models themselves, has become prime attacker real estate.
This should reframe how security teams think about AI infrastructure risk. Most enterprise AI governance conversations focus on model behavior, prompt injection and output safety. This incident is a reminder that the plumbing underneath those models, gateways, orchestration layers, vector database connectors, carries the same supply-chain risk as any other piece of enterprise software, and in this case a materially higher payoff for the attacker because of what flows through it.
What to do this week
First, determine whether any system in your environment installed LiteLLM 1.82.7 or 1.82.8 between March 24, 2026, 10:39 UTC and 16:00 UTC. Build logs, artifact registries and dependency lockfile history should give you a definitive answer; if you cannot reconstruct that window with confidence, treat every LiteLLM deployment built during that quarter as suspect. Second, rotate every credential any affected system could have reached, cloud keys, Kubernetes tokens, SSH keys, and every AI provider API key configured in that environment, not just the LiteLLM package itself.
Third, search your GitHub organizations for repositories named tpcp-docs or docs-tpcp, the indicator pattern the FBI flagged as tied to this campaign's follow-on activity, since the attackers used victims' own GitHub accounts as exfiltration and hosting infrastructure. Finally, use this incident to push for .pth-file execution monitoring and CI/CD pipeline integrity checks, including verifying that scanning tools like Trivy themselves have not been tampered with, as a standing control rather than a one-time remediation. The attackers targeted the scanner precisely because everyone trusts it unconditionally.
