LiteLLM Supply Chain Breach Hit 2,500 Companies and 434K CI/CD Pipelines

Marcus Chen Staff Engineer, Backend & Cloud, YuSMP Group · Infrastructure security and cloud architecture for US/EU products

The short answer

How Trivy became the entry point

The attack exploited a single, unrevoked token three steps deep in an open-source dependency chain. TeamPCP initially compromised Aqua Security's Trivy vulnerability scanner on March 19, 2026 — gaining access to a PyPI publishing token that LiteLLM's CI pipeline used for automated releases. When LiteLLM's build system ran Trivy as part of its standard release workflow, the compromised scanner injected malicious code into the outgoing package.

The result was LiteLLM versions 1.82.7 and 1.82.8, published to PyPI on March 24. Both contained a file named litellm_init.pth, which Python loads automatically via the .pth file mechanism when any Python process starts — meaning the credential harvester executed even if LiteLLM was never directly imported. The malicious packages were live for roughly 40 minutes (approximately 10:39 to 16:00 UTC) before PyPI removed them.

This attack pattern is worth studying for what it reveals about modern CI/CD risk. The target was not LiteLLM directly. The target was a security tool that LiteLLM trusted implicitly, whose credentials were never scoped to read-only or time-limited. One unrotated token in a scanner's release pipeline translated into a poisoned package distributed to an unknown number of downstream build systems within the hour.

What CloudSEK's report revealed

CloudSEK's August 11, 2026 analysis reconstructed the exposure by analyzing approximately 434,000 captured files from attacker infrastructure. The firm identified more than 2,500 organizations as high-confidence exposure matches — meaning their build environments showed signs of having installed the backdoored releases during the active window.

Named organizations in CloudSEK's high-confidence dataset include NVIDIA, Amazon Web Services, Cisco Systems, Samsung Electronics, Salesforce, Deloitte, Siemens, S&P Global, ServiceNow, Vodafone, Volkswagen, FedEx, Thales, Zscaler, and the London Stock Exchange Group. The breadth of the list reflects how widely LiteLLM is used as an AI gateway library across industries ranging from enterprise SaaS to logistics infrastructure.

An important caveat in the CloudSEK report: the 2,500-plus figure describes reconstructed exposure, not confirmed compromise. CI/CD pipelines install and cache packages differently, and the effect of a package install depends on whether a Python process was actually started during the window, what secrets were accessible in that environment, and whether network connectivity to the attacker domain was available. Teams should investigate their own build logs rather than wait for an official notification.

What was exfiltrated and why it still matters

The litellm_init.pth harvester targeted a broad set of credentials and environment state: cloud API keys including OpenAI and Anthropic tokens, AWS access keys and secret keys, Azure credentials, GCP service account tokens, Kubernetes ServiceAccount tokens, SSH private keys, database passwords, and general environment variables captured at Python process startup. All data was exfiltrated to a domain controlled by TeamPCP — models.litellm[.]cloud — which mimicked a legitimate LiteLLM infrastructure endpoint.

The reason the FBI's July 2026 advisory matters is that credential rotation following a supply chain event is slower and less complete than it should be. Secrets embedded in deployed containers, stored in CI/CD secret managers without automatic rotation, or shared across multiple services are frequently missed in incident response sweeps. The advisory specifically noted that harvested AI provider API keys — OpenAI, Anthropic, and similar — carry particular risk because they can be used silently for model inference cost fraud or for injecting malicious outputs into AI-dependent workflows without triggering traditional intrusion detection signals.

CloudSEK's report also noted that TeamPCP used follow-on infrastructure — GitHub and GitLab repositories named tpcp-docs or docs-tpcp — for ongoing command-and-control, meaning some compromised environments may have an active persistence mechanism that outlasted the initial credential harvest.

What it means for US & EU software teams

For teams actively building AI-powered products, the LiteLLM incident illustrates a specific class of risk that is growing as AI libraries become foundational infrastructure: the trust chain for a Python package includes every tool in the package publisher's own release pipeline, not just the package itself. LiteLLM did not write the malicious code. Its build system pulled a compromised dependency automatically, as it was designed to do. The attack succeeded precisely because the automated tooling worked as expected.

For US and EU engineering organizations, the practical implication is that dependency auditing needs to extend beyond direct dependencies and their transitive graph. Build-time tools — scanners, formatters, linters, test runners — that hold publishing credentials or execute with access to secrets require the same rotation and least-privilege policies as application secrets. A Trivy token that can push to PyPI should not exist; if it must, it should be scoped, time-limited, and rotated on a schedule shorter than any attacker's dwell time.

For organizations subject to EU NIS2 or DORA requirements, a supply chain incident of this scope — affecting hundreds of thousands of CI/CD pipelines including at financial institutions, logistics operators, and critical infrastructure operators — warrants review against incident reporting obligations. NIS2 requires notification to competent authorities within 24 hours of becoming aware of a significant incident; organizations that are only now identifying March exposure through CloudSEK's August report should consult legal and compliance counsel on timing obligations.

For FinTech and HealthTech companies in particular: AI provider API keys stolen from a build pipeline that also held HIPAA-regulated data or payment processing environment variables create a compound risk. The exfiltrated OpenAI or Anthropic key may itself be low-value, but the environment variable dump it traveled with could contain production database passwords or PCI-scoped service credentials.

Three-step remediation checklist

If your organization uses LiteLLM and has not completed a post-incident review, prioritize these three actions:

1. Audit build logs for the exposure window. Search your CI/CD platform's artifact logs for installs of litellm==1.82.7 or litellm==1.82.8 on March 24, 2026 between approximately 10:39 and 16:00 UTC. If your pipeline uses caching, also check whether cached versions from that window were replayed in subsequent builds.

2. Rotate all secrets accessible to affected pipelines. This includes cloud provider API keys (AWS, Azure, GCP), AI provider API keys (OpenAI, Anthropic, and any other provider whose credentials were in environment variables), Kubernetes ServiceAccount tokens, SSH keys used by the build runner, and database passwords accessible to the build environment. Do not limit rotation to secrets you believe were directly used — rotate everything that was in scope of the Python process.

3. Check for persistence indicators. Search your GitHub and GitLab organizations for repository references to tpcp-docs or docs-tpcp. Review network logs from build runners for outbound connections to models.litellm.cloud on and after March 24. If you find either indicator, treat the affected build environment as potentially still compromised and engage incident response resources.

Frequently asked questions

Sources

SecurityWeek — Over 2,500 Organizations Impacted by LiteLLM Supply Chain Attack, August 2026
The Hacker News — Malicious LiteLLM Releases Tied to Trivy Hack May Have Exposed 2,100+ Organizations, August 2026
CloudSEK — 2,500+ Companies and 434,000 CI/CD Pipelines Exposed (primary research), August 11, 2026