A five-month gap between compromise and disclosure
On August 13, 2026, Help Net Security reported that a 153GB archive of stolen credentials — 433,909 files, with 118,829 CI runner dumps traced to 2,488 corporate domains including AWS, Samsung, Cisco, and Salesforce — had surfaced from the March 2026 LiteLLM supply-chain attack. Threat-intelligence firm Hudson Rock, which obtained and analyzed the archive, framed its release as a "global ethical disclosure effort" meant to let organizations respond before criminals weaponize the data. CloudSEK independently corroborated the scale, tallying over 2,500 organizations and roughly 434,000 exposed CI/CD pipeline files, and called it the largest AI-infrastructure supply-chain breach of the year.
The underlying compromise happened five months earlier. On March 19, 2026, the threat actor group TeamPCP exploited an incomplete credential rotation to force-push malicious commits into the Trivy vulnerability scanner and its associated GitHub Actions — 76 of 77 trivy-action tags and all seven setup-trivy tags, according to the GitHub Security Advisory tracking the incident as CVE-2026-33634. Because LiteLLM's build pipeline installed Trivy automatically, the poisoned scanner gave attackers read access to LiteLLM's own CI environment, including its PyPI publishing token. On March 24, TeamPCP used that token to push two backdoored LiteLLM releases, versions 1.82.7 and 1.82.8, each carrying a malicious .pth file that harvested SSH keys, cloud credentials, and Kubernetes tokens on every Python startup.
What actually contained it — and what didn't
The part of this story that gets less attention than the headline number is how fast the ecosystem's own machinery worked. According to PyPI's own incident report, the malicious LiteLLM release was quarantined roughly two and a half hours after upload, following thirteen malware reports filed through PyPI's built-in reporting feature — even as the packages racked up over 119,000 downloads in that window. GitHub's advisory database flagged the compromised Trivy tags as CVE-2026-33634 with a 9.3–9.4 CVSS score. CISA added the flaw to its Known Exploited Vulnerabilities catalog on March 26, ordering federal civilian agencies to remediate by April 9 under Binding Operational Directive 22-01, as Security Affairs reported at the time.
That federal deadline is the only formal, legally binding response this incident produced — and it applied exclusively to U.S. government agencies. None of it reached the roughly 2,500 private companies whose CI/CD credentials were sitting in a criminal archive, because no equivalent disclosure or reporting obligation covers them. Those organizations found out their secrets had been harvested not from a regulator, but from a private threat-intel firm's PR effort, months after the fact.
The case for mandatory reporting — and its limits
There is a real argument for closing that gap. If AWS, Samsung, Cisco, and Salesforce had been required to report anomalous CI/CD credential exposure within a fixed window, the five-month lag between the March compromise and the August disclosure might have been weeks instead. That is the logic behind CIRCIA, the Cyber Incident Reporting for Critical Infrastructure Act, whose final rule CISA now expects to issue this fall, per Federal News Network's July 2026 reporting — a rule that would require 72-hour incident reporting and 24-hour ransomware-payment reporting across roughly 300,000 entities in sixteen critical-infrastructure sectors.
But CIRCIA's own record shows the difficulty of drawing that net correctly. Federal News Network notes the draft rule has already drawn criticism for covering an unwieldy 300,000 entities while leaving "cyber incident" ambiguously defined — and it is not built around software supply-chain compromises like a poisoned PyPI package at all. Stretching a rule already struggling with scope to also capture every open-source maintainer whose build pipeline gets poisoned risks two failure modes at once: overloading a compliance regime that critics already call too broad, and imposing formal reporting duties on unpaid maintainers of infrastructure like Trivy, who have every incentive to disclose quickly already and little capacity to absorb new liability.
What proportionate policy looks like here
The mechanisms that actually worked in this incident were not statutory — they were engineering defaults. PyPI's quarantine turned on a built-in abuse-reporting pipeline and a two-and-a-half-hour response time, not a legal deadline. In its own post-incident guidance, PyPI pointed toward Trusted Publishers (short-lived, OIDC-based publishing credentials instead of long-lived API tokens), mandatory two-factor authentication, dependency cooldowns, and lockfile-pinned installs — all technical controls that shrink the blast radius of exactly this kind of attack chain, where one compromised scanner cascaded into a package registry compromise.
The right response to a 153GB leak is not to wait for a slow-moving, contested federal rule to eventually cover software supply chains by extension. It is to push registries, package maintainers, and enterprise CI/CD operators toward the controls that already demonstrably worked here, faster than any mandate could have, while reserving reporting obligations for the narrower set of cases — critical infrastructure operators, not every PyPI maintainer — where the case for them is actually proportionate to the burden.