The LiteLLM Supply Chain Breach Just Cost Six Major Enterprises Their Secrets
Cybersecurity

The LiteLLM Supply Chain Breach Just Cost Six Major Enterprises Their Secrets

A poisoned Trivy container turned into a full CI/CD compromise at LiteLLM, and threat intelligence firm Hudson Rock traced the fallout to source code theft at Cisco, a 4-terabyte leak at Mercor, and 250-plus enterprise disclosures in total.

PublishedAugust 24, 2026
Read time5 min read
Share

How one poisoned scanner became a global breach

The attack began with Trivy, a widely deployed open-source vulnerability scanner used across countless CI/CD pipelines. Attackers, tracked as TeamPCP, compromised Trivy's GitHub Actions pipeline and used that access to steal the PyPI publishing credentials for LiteLLM, a popular library for interfacing with large language model APIs. From there, they published malicious versions of the LiteLLM package, numbered 1.82.7 and 1.82.8, that used a Python startup hook to harvest environment variables, configuration files, and establish persistence through a systemd backdoor on any machine that installed the compromised release, all while the package continued to look like a routine version bump to anyone watching their dependency feed.

Because both Trivy and LiteLLM sit inside development and CI pipelines rather than production applications, the compromise had an unusually wide blast radius. Any organization that ran the poisoned package inside a build runner effectively handed over whatever secrets that runner had access to: cloud credentials, source control tokens, database passwords, and API keys for dozens of internal and third-party systems, harvested automatically the moment the malicious startup hook executed without requiring any further action from the attacker.

The scale of the disclosure effort

Hudson Rock's threat intelligence team obtained the raw exfiltrated data, a 153GB archive containing more than 433,000 files, and has since completed over 250 ethical disclosures to affected organizations. More than 30 of those organizations are Fortune 500 or S&P 500 companies, spanning technology, telecom, automotive, government, retail, healthcare, and finance. That breadth is the clearest evidence yet of how deeply a single compromised open-source dependency can penetrate the enterprise software supply chain before anyone notices.

The stolen data included AWS, GCP, and Azure IAM keys, Kubernetes service account tokens, GitLab and GitHub personal access tokens, database passwords, and credentials for Salesforce, Slack, and Microsoft Azure, alongside AI provider API keys. In other words, this was not a narrow leak of one system's data. It was a credential harvest across the full breadth of modern enterprise infrastructure, collected indiscriminately from whatever each affected organization's CI runners happened to touch.

Six breaches that show the range of damage

The specific fallout cases documented by Hudson Rock illustrate how differently this played out depending on what each victim's CI pipeline had access to. At Guesty, AWS access keys exposed in plain-text CI logs led to theft of 700GB of data, including 4 million customer emails and integration data tied to Airbnb and Booking.com. At S&P Global, intercepted AWS STS tokens during Terraform workflows exposed 250GB of internal architectural secrets and thousands of additional credentials including JWTs and RSA private keys. Cisco had source code stolen from critical internal repositories after a poisoned Trivy container scraped tokens from its runner environment.

The European Commission suffered a severe cloud breach during an AWS Terraform deployment, exposing IAM credentials and a hardcoded SSH private key that enabled lateral movement across its GitLab infrastructure, a striking outcome for a government body. But the most damaging case by far was Mercor, where attackers exfiltrated 4 terabytes of data including 939GB of proprietary source code, AI training methodologies, and biometric data belonging to more than 40,000 contractors. The Lapsus$ extortion group claimed to have permanently sold Mercor's data to Chinese enterprises, and the fallout has already included a paused data contract with Meta and multiple class-action lawsuits.

Why open-source CI dependencies are an underpriced risk

Most enterprise risk registers treat open-source dependency risk as a code-level concern, scanning for known vulnerabilities in libraries that ship inside applications. This breach demonstrates a different and arguably larger category of exposure: tools like Trivy and LiteLLM that live inside the CI/CD pipeline itself, with direct access to the secrets and credentials that make deployment possible. A vulnerability in an application library exposes that application. A compromise of a CI-pipeline tool exposes everything the pipeline can touch, which for most enterprises means nearly all of it, spanning cloud infrastructure, source control, and every downstream SaaS integration a build process ever authenticates against.

This is precisely the blind spot that hit organizations as disciplined as Cisco and S&P Global. Both run mature security programs, and both were breached because a trusted third-party tool embedded in their build process was compromised upstream, well outside the scope of their own code review. No amount of application-layer security testing would have caught this, because the vulnerable surface was the infrastructure quietly building and deploying the application every day, a layer most security testing programs never touch.

The pipeline governance decision this forces

For CTOs and CISOs, the direct lesson is that CI/CD pipeline tooling deserves the same credential-scoping discipline applied to production systems, and often does not get it. Build runners frequently carry broad, long-lived credentials because narrowing them is inconvenient, exactly the condition that turned a compromised scanner into a multi-terabyte breach at several of these organizations. Short-lived, narrowly scoped tokens, secrets that never touch plain-text logs, and network egress controls on build environments would have limited the blast radius even after the initial compromise.

This is also a governance question about how much unvetted trust flows into your pipeline through transitive dependencies you never directly chose. Every organization running Trivy trusted LiteLLM's supply chain by extension without ever evaluating it. Enterprises serious about supply chain risk need an inventory of every tool with pipeline-level access, not just the applications they ship, and a plan for rotating credentials fast when any one of those tools is compromised.

Tagged#news#security#cybersecurity#breach#cisa#ransomware#zero-day#supply-chain#ai-security#LiteLLM#Trivy#CI/CD security#Hudson Rock#Mercor breach#Cisco