How a Poisoned Scanner Reached 2,500 Companies Through One AI Supply-Chain Package

New data published around August 11, 2026, puts a hard number on a breach the software world has been underestimating since spring. The March compromise of LiteLLM — the open-source gateway thousands of teams use to route traffic to large language models — may have exposed secrets belonging to more than 2,500 organizations, according to a dataset analyzed by the threat-intelligence firm CloudSEK. The firm says the attackers walked away with roughly 434,000 files pulled from build pipelines around the world. The reason the count keeps climbing is the shape of the attack. Nobody breached 2,500 companies one at a time. They poisoned one tool those companies trusted, and let the tool do the reaching. Here is the chain, as reported by LiteLLM and multiple responders. On March 19, 2026, attackers compromised Trivy, a widely used open-source security scanner, and pushed malicious Trivy images to Docker Hub. That foothold — later cataloged as CVE-2026-33634 — gave them a way into the developer and CI/CD workflows that ran the scanner. From there, the campaign moved downstream. Two malicious LiteLLM releases, versions 1.82.7 and 1.82.8, were published to the PyPI package index carrying credential-stealing code, per LiteLLM’s own security advisory. Anyone whose automated build pulled the latest version during the window got the payload. That window was short. Reporting on the CloudSEK findings by The Hacker News puts the malicious versions on PyPI for roughly 40 minutes. It did not need longer. A modern build pipeline installs dependencies unattended, dozens of times an hour, and it does so with live credentials sitting in environment variables. The malware read exactly those: cloud access keys, SSH keys, Kubernetes tokens, database passwords, and other secrets stored where automated builds run. Forty minutes of an unattended process is plenty of time to copy a file. What the attackers actually reached The exposure did not stop at LiteLLM’s direct users. CloudSEK’s analysis of the captured dataset maps potential impact to over 2,500 companies and 434,000 CI/CD pipelines — a figure that includes downstream projects and internal systems that inherited the stolen keys. SecurityWeek’s reporting lands in the same range. Some of the named fallout is worth stating plainly, because it shows what stolen build credentials buy an attacker. The security vendor Checkmarx has said credentials taken in the campaign let intruders reach its GitHub repositories and publish malicious artifacts. Investigators at the SANS Internet Storm Center have tracked the same campaign to the theft of Cisco source code through a Trivy-linked breach. And CERT-EU assessed with high confidence that a European Commission AWS account was compromised through the Trivy chain, with roughly 91.7 GB of compressed data pulled out. One poisoned scanner, and the blast radius runs from a startup’s staging environment to an EU institution’s cloud tenant. Google’s threat group tracks the operators as UNC6780; much of the industry calls them TeamPCP. I’ll label the attribution as reported assessment rather than settled fact — that is how the responders themselves frame it. What is not in dispute is the target selection. This crew went after the tooling that developers and security teams install by default: a scanner, a linter, an AI gateway. These are the supply chain cyberattacks that work precisely because the victim’s own automation trusts the poisoned component and runs it without a human in the loop. Why an AI package was the payload carrier It is not a coincidence that LiteLLM was the vehicle. AI gateways have become plumbing. A team stands one up to manage keys and route requests across model providers, and within a quarter it is wired into half the internal apps — which means it also holds, or sits next to, a lot of credentials. Securing that new layer is its own discipline, and most programs are still catching up on AI security fundamentals like where model keys live and which pipelines can touch them. An attacker who wants credentials at scale now has a good reason to target the AI toolchain specifically: that is where the fresh, high-value keys are pooling. The part defenders can act on The instinct after a supply-chain story is to ask how fast you patched. That is the wrong question here. The malicious LiteLLM versions were live for less than an hour and are long gone; LiteLLM has since shipped a clean 1.83.0 built on a rebuilt, isolated CI/CD pipeline. Patching is done. The exposure is not, because stolen secrets do not expire when the bad package is pulled. So treat this as a credential incident, not a patching one. Concretely: Rotate anything that a build could have seen. If your pipelines installed LiteLLM 1.82.7 or 1.82.8 — or ran the compromised Trivy images — assume every secret reachable from that environment is burned. Rotate cloud access keys, SSH keys, Kubernetes tokens, and database credentials referenced in those pipelines. A key that might be in a 434,000-file dump is not a key you keep. Pin dependencies by hash and require provenance. Installing “the latest version” unattended is what turned 40 minutes into 2,500 companies. Pin to known-good hashes, and prefer signed artifacts so a swapped package fails the build instead of running. Separate the pipeline that scans from the pipeline that publishes. A poisoned scanner should not be able to reach the credentials that push to your package registry or your repos. Checkmarx’s stolen GitHub access is the cautionary tale. Check CISA KEV, then check your own history. CVE-2026-33634 has been on CISA’s Known Exploited Vulnerabilities catalog since March 26, with a federal remediation deadline of April 8. Search your build logs for the affected LiteLLM versions and Trivy image digests. If you can’t tell whether they ran, that gap is its own finding. The single most useful thing to fix long-term is the assumption underneath all of this: that a tool you scan with is safer than the code you scan. In March, it was the other way around.