A compromised open source vulnerability scanner has cascaded into one of 2026’s largest software supply chain breaches, exposing 153 gigabytes of stolen credentials tied to nearly 2,500 companies, according to research published by cybercrime intelligence firm Hudson Rock.
A scanner update becomes the entry point
The breach began, according to Hudson Rock’s analysis, with Trivy, a widely used open source vulnerability scanner. On March 19, 2026, a cybercriminal group tracked as TeamPCP used stolen credentials to publish a poisoned version of Trivy. When the build pipeline for LiteLLM, an open source AI proxy gateway used to route requests across large language model providers, automatically pulled in the compromised scanner, the attackers gained read access to the pipeline’s runner environment. From there they harvested PyPI publishing tokens and used them to push two malicious LiteLLM releases, versions 1.82.7 and 1.82.8, on March 24.
Any organization that installed those two versions inherited a credential stealer embedded in a dependency they trusted implicitly: the tool meant to route their AI infrastructure traffic.
Media Partner
The scale: 434,000 files, 2,488 corporate domains
Hudson Rock says it obtained and analyzed the resulting archive: 153 gigabytes across 433,909 files, including 118,829 CI runner dumps the firm was able to link back to 2,488 corporate domains. The dumps contained AWS secret access keys, Azure environment variables, Salesforce client secrets, Slack signing secrets, GitLab variables, internal JWTs, NPM and Bitbucket deployment tokens, Elastic API keys, and API keys for AI providers. Companies named in the exposed data include NVIDIA, Volkswagen, Microsoft, FedEx, Samsung, Cisco, and Salesforce, though inclusion in the dataset does not by itself confirm those organizations suffered a downstream compromise.
Security researcher Kevin Beaumont independently reviewed the archive and confirmed its authenticity, according to Hudson Rock. Hudson Rock co-founder and CTO Alon Gal said the firm is “leveraging this data for a global ethical disclosure effort,” framing the release as an opportunity to help affected organizations respond before criminal groups weaponize the data themselves.
Why the CI runner, not just the package, is the real exposure
The detail that should worry security leaders more than the malicious package itself is what a CI runner dump actually contains. Runner environments routinely carry every credential a pipeline touches during a build: cloud provider keys, source control tokens, secrets manager pulls, and increasingly, API keys for the AI services that pipeline now calls. A single poisoned dependency did not just compromise LiteLLM’s own users; it compromised the ambient trust that CI/CD environments extend to every tool in the chain, AI proxy included.
This is the same failure mode CyberTech has tracked through 2026’s other build pipeline compromises. ChainDrop’s self-propagating npm worm infected more than 400 packages by republishing through hijacked maintainer credentials, and the response from GitHub and PyPI has been to make publish delays the default rather than trust every release the moment it lands. The LiteLLM incident shows why that shift matters: the compromise did not require a novel exploit in LiteLLM itself, only stolen publishing access and a build pipeline that trusted a routine scanner update by default.
The AI layer inherits software supply chain risk it did not budget for
Most enterprise AI security programs were built around model risk: prompt injection, data leakage, output validation. The LiteLLM breach sits one layer down, in the plumbing that routes requests to those models in the first place. An AI gateway or proxy sits between an organization’s applications and every LLM provider it calls, which means its dependencies inherit the same blast radius as any other piece of security-critical infrastructure. Treating AI tooling as exempt from standard software supply chain controls, because it feels new, is precisely the gap this breach exploited.
What it means for the security leader
Three implications follow directly from Hudson Rock’s findings. First, AI infrastructure tooling, proxies, gateways, and orchestration layers, is now squarely inside the software supply chain threat model, not adjacent to it. Apply the same dependency pinning, provenance verification, and update review to AI proxy packages that production credential access anywhere else would demand.
Second, CI runner secrets represent a bigger blast radius than most inventories assume. If a build pipeline’s runner environment can read cloud keys, SaaS tokens, and AI provider credentials all in one place, that environment deserves the isolation and least privilege scoping normally reserved for production systems. Short lived, narrowly scoped tokens rather than long lived static secrets would have limited how much value this breach handed attackers even after the compromise occurred.
Third, any organization that pulled LiteLLM 1.82.7 or 1.82.8, or that ran Trivy scans during the affected window, should treat every credential those pipelines touched as burned: rotate cloud keys, SaaS API tokens, and AI provider keys, and review CI logs for the affected period for unexpected outbound connections.
What to do now
Security teams should confirm whether LiteLLM was in their AI infrastructure stack and, if so, whether versions 1.82.7 or 1.82.8 were ever installed. Rotate any credential CI runners exposed to those pipelines during March 2026, not just the ones believed to be AI related. Review dependency pinning policies for scanning and security tooling specifically, since this breach began with the tool meant to catch vulnerabilities, not with the target application itself. Organizations wanting to check their own domain-level exposure can consult Hudson Rock’s published research directly.
Beyond the immediate rotation work, this breach is a reasonable trigger to audit which build and scanning tools in the pipeline are allowed to publish or fetch on their own schedule, without a human or a gated review step in between. A scanner that can silently update itself, and a publishing token that never expires or narrows its scope, are the two conditions that turned a compromised third-party tool into a multi-thousand-company breach. Neither condition is unique to LiteLLM or to Trivy; most CI/CD environments have some version of both, quietly, by default.
Source: Hudson Rock
