A 153-gigabyte archive containing 433,909 files stolen during a software supply chain attack in March 2026 has surfaced, with cybersecurity researchers linking the stolen data to nearly 2,500 organizations worldwide. The disclosure, confirmed by threat-intelligence firm CloudSEK in a report published August 11, 2026, marks the most complete accounting yet of the fallout from one of 2026’s most consequential developer-ecosystem breaches.
How the attack unfolded
On March 19, 2026, a threat actor used compromised credentials to publish a malicious Trivy v0.69.4 release and force-push malicious commits to 76 of 77 version tags in the aquasecurity/trivy-action repository. The open-source Python library and proxy server LiteLLM was compromised after its CI pipeline installed the compromised Trivy version automatically.
The packages (versions 1.82.7 and 1.82.8) were published by a threat actor known as TeamPCP after they obtained the maintainer’s PyPI credentials through a prior compromise of Trivy, an open-source security scanner used in LiteLLM’s CI/CD pipeline. The compromised scanner ran inside LiteLLM’s build environment with legitimate read access, exfiltrating the project’s PyPI publishing credentials.
The compromised PyPI packages were LiteLLM versions 1.82.7 and 1.82.8. Those packages were live on March 24, 2026 from 10:39 UTC for about 40 minutes before being quarantined by PyPI, according to LiteLLM’s own security update; other security firms including Snyk reported the malicious versions were available for approximately three hours before PyPI quarantined the package.
The malicious releases deployed a multi-stage credential stealer. Version 1.82.8 shipped a .pth file called litellm_init.pth that executed on every Python process startup, not just when LiteLLM was imported.
LiteLLM is a widely used Python package downloaded 3.4 million times per day that serves as a unified gateway to multiple LLM providers. It is commonly used in AI agent frameworks, MCP servers, CI/CD pipelines, and production inference infrastructure. Its position within AI and development infrastructure makes affected environments particularly valuable, as they can contain cloud credentials, repository tokens, Kubernetes credentials, and keys for AI services.
Scale of exposure revealed
CloudSEK counts more than 2,500 potentially exposed organizations and roughly 434,000 CI/CD pipelines, while Hudson Rock says it independently obtained the attackers’ raw exfiltration archive and attributed 118,829 CI runner dumps to 2,488 corporate domains.
Cybersecurity firm Hudson Rock obtained a 153GB archive containing 433,909 files associated with the TeamPCP campaign. After analyzing the material, the company attributed 118,829 CI runner dumps to 2,488 corporate domains, with the records containing environment variables, cloud credentials, API tokens, configuration files, and other secrets collected from affected systems. Exposed data includes AWS secrets, GitLab identities, Salesforce and Slack credentials, Azure secrets, and AI provider API keys.
CloudSEK’s high-confidence list includes NVIDIA, Amazon Web Services, Samsung Electronics, Cisco Systems, Salesforce, ServiceNow, Siemens AG, S&P Global, London Stock Exchange Group, FedEx, Volkswagen, Deloitte, Thales, X Corp, and Zscaler. CloudSEK is explicit that its numbers describe reconstructed exposure and should not be read as proof that every listed organization was compromised.
Hudson Rock co-founder and CTO Alon Gal said the firm is “leveraging this data for a global ethical disclosure effort.”
The ecosystem compromise is tracked as CVE-2026-33634, added to CISA’s Known Exploited Vulnerabilities catalog on March 26. CISA lists the vulnerability with a CVSS score of 9.3 and describes it as the Aqua Security Trivy Embedded Malicious Code Vulnerability, citing evidence of active exploitation.
Why the risk has not faded
CloudSEK’s exposure report warns that stolen credentials can remain useful long after malicious package versions disappear, making sustained post-incident hunting essential. Removing the malicious releases from PyPI did not close the incident. Any credential copied while the poisoned package was active stays valid until the owner rotates or revokes it, and the package’s removal does nothing on its own.
FBI FLASH guidance cited in CloudSEK’s August write-up warned that affiliated actors may weaponize harvested secrets long after the original package is gone.
This kind of risk mirrors what security researchers have flagged in other developer-ecosystem incidents: even after a short exposure window, the downstream exposure can compound for months. For organizations thinking about how credentials underpin broader account security, the breach also illustrates why hardware-backed protections discussed in coverage of the quantum security chip race exist, yet do not protect the server-side CI/CD pipeline secrets that attacks like this one specifically target.
Organizations that ran the affected releases should audit their environments for LiteLLM versions 1.82.7 and 1.82.8 and treat any secrets accessible to the LiteLLM environment as compromised. Snyk identifies LiteLLM 1.82.6 and earlier as unaffected by the malicious releases.
A blueprint for cascading supply-chain risk
Hudson Rock’s Gal described the broader lesson: how supply chains have evolved so that a single upstream breach can affect thousands of companies simultaneously, with a brief exposure window allowing more than 430,000 instances in which secrets were harvested.
The malicious releases used a Python .pth startup hook. This technique allowed the payload to run automatically when Python started, even if an application did not directly import the LiteLLM library. That detail let the payload sidestep common install-time protections security teams rely on.
The incident underscores a growing pattern security analysts have flagged across 2026: complex software supply chains, particularly those built around AI tooling and open-source dependencies that sit inside virtually every commercial codebase, create entry points that individual organizations cannot easily audit or control on their own.
Defenders are now being urged to rotate cloud IAM keys and access tokens, review audit logs for anomalous activity dating back to March 24, and check for unauthorized .pth files and suspicious systemd services. These LiteLLM versions deployed a three-stage payload: credential harvesting, Kubernetes lateral movement, and persistent backdoor for remote code execution. Organizations should consider any secret accessible to the LiteLLM library as compromised, including those present in process memory, injected into the job, stored on disk, or retrievable through an instance metadata service.
