A 40-minute window in March 2026 is now producing one of the largest credential exposures on record. Threat actor group TeamPCP used stolen PyPI publishing tokens to push two malicious releases of LiteLLM, the widely deployed open-source AI proxy and Python library, and the resulting credential haul has since surfaced as a bulk archive circulating among researchers. Tenable's advisory for CVE-2026-33634 (GHSA-5mg7-485q-xm76) confirms versions 1.82.7 and 1.82.8 carried an infostealer payload and rates the issue critical. CloudSEK puts potential exposure at more than 2,500 organizations and roughly 434,000 CI/CD pipelines. Hudson Rock, working from a recovered archive, attributes 118,829 CI runner dumps to 2,488 corporate domains. Kevin Beaumont, who reviewed samples independently, said he confirmed the data is legitimate against multiple victim organizations.
What Happened
The LiteLLM compromise was not a direct attack on LiteLLM. It was collateral damage from an earlier TeamPCP operation against Aqua Security's Trivy vulnerability scanner.
Per Help Net Security, TeamPCP used stolen credentials to publish a compromised Trivy release on March 19, 2026. LiteLLM's build pipeline installed Trivy automatically and, critically, without pinning it to a verified version. The poisoned scanner ran inside LiteLLM's CI runner with read access to the environment, which handed the attackers LiteLLM's PyPI publishing tokens. On March 24, those tokens were used to publish LiteLLM 1.82.7 and 1.82.8 to the Python Package Index.
CloudSEK described the chain bluntly: "Trivy, then the [LiteLLM] build system, then the LiteLLM release: one unrevoked token, three tools deep."
The malicious packages were live for approximately 40 minutes before quarantine. Gridinsoft, citing LiteLLM's own incident notice, places publication at 10:39 UTC on March 24. That notice also states the official LiteLLM Cloud service and the official LiteLLM Proxy Docker image were not affected by this package path.
Trivy and LiteLLM were not the only casualties. Ars Technica reports that KICS and the Telnyx Python SDK were also infected in the same campaign.
What Was Taken
Accounts of the archive size differ significantly, and the difference is not trivial. Ars Technica reports Hudson Rock analyzed a 195TB file. Help Net Security and CyberInsider both describe a 153GB RAR archive containing 433,909 files. The 153GB figure appears in the two most recent and most specific accounts, including direct comment from Hudson Rock CTO Alon Gal, but the discrepancy has not been publicly reconciled. Treat the volume as unsettled.
Victim counts also vary by methodology. CloudSEK's figure of "2,500+ organizations and 434,000 CI/CD pipelines" describes reconstructed potential exposure. Hudson Rock's 2,488 corporate domains and 118,829 CI runner dumps describe what was actually attributable inside the archive it obtained. Ars Technica frames CloudSEK's finding as credentials that "could allow attackers to gain access to more than 2,500 organizations."
The secret types are consistent across every source: cloud access keys, repository tokens, SSH keys, Kubernetes secrets and .kube/config files, .aws/credentials, package publishing credentials, environment variables, database passwords, configuration files, and AI provider API keys.
The named victim lists are extensive. Between CloudSEK and Hudson Rock, reported organizations include Microsoft, Amazon/AWS, Nvidia, Cisco, Samsung, Salesforce, ServiceNow, Siemens, Volkswagen, FedEx, Orange, HP, BT Group, Zscaler, NGINX, Deutsche Bahn, London Stock Exchange Group, S&P Global, John Deere, Epic Games, TomTom, Accenture Federal Services, and Regeneron Pharmaceuticals.
An important caveat that both Cyber Security News and Gridinsoft flag explicitly: appearing on an exposure list is not proof of breach. Exposure indicates a credential was readable by the malicious process, not that it was used.
Why It Matters
This incident is the clearest demonstration to date that build-system trust is transitive and that transitivity is not bounded.
The attackers never touched LiteLLM's repository, never phished a LiteLLM maintainer, and never exploited a LiteLLM vulnerability. They compromised a security tool that LiteLLM's pipeline trusted implicitly, and that trust carried them into a package that thousands of downstream organizations trust implicitly in turn. One unrotated token propagated three tools deep and reached hundreds of thousands of pipelines.
The 40-minute exposure window is the part defenders should not find reassuring. As CloudSEK put it, "automated build systems compress time." Scheduled jobs, dependency resolvers, ephemeral runners, developer laptops, and cached container layers replicate a malicious artifact far faster than any human response cycle. The firm notes that the forensic and rotation window therefore extends well past the moment the package was pulled from PyPI.
There is also an active downstream threat. CloudSEK cites an FBI FLASH advisory from July 2026 (FLASH-20260702-01) warning that affiliated actors are likely to weaponize the harvested credentials long after the original intrusion, raising the prospect of further supply chain attacks seeded from this dataset.
Hudson Rock says it is using the archive for what Gal called "a global ethical disclosure effort," to reach organizations before the data is weaponized publicly. Neither Hudson Rock nor CloudSEK has identified how they obtained the material.
Beaumont's assessment is worth quoting directly: "It's a massive supply chain breach due to poor AI security, not because AI is the threat, but teens can run circles around orgs obsessed with rushing out AI and poor DevOps security."
TeamPCP claimed responsibility and researchers have largely corroborated the claim. Ars Technica describes the group as "ramshackle but extremely capable" and largely composed of teenagers; CyberInsider notes it emerged in late 2025.
The Attack Technique
The two malicious releases used different execution triggers, and the second is the more dangerous of the pair.
Per Tenable's advisory, version 1.82.7 injected the payload directly into the LiteLLM proxy server module. Version 1.82.8 instead shipped a .pth file, a Python site-packages mechanism that executes at interpreter startup. That means the payload ran on any Python invocation on the host, with no application ever importing LiteLLM. Simply having the package installed was sufficient.
CyberInsider, drawing on investigations from Endor Labs, Snyk, Trend Micro, and Cycode, describes a multi-stage credential stealer that harvested environment variables and local credential files, attempted lateral movement within Kubernetes, and installed persistence via a systemd service. Cyber Security News adds that on CI runners the payload actively sought elevated access before enumerating secrets. Ars Technica reports the malware also scraped process memory. Collected data was encrypted and exfiltrated to an attacker-controlled domain.
The persistence detail matters operationally: Tenable warns that litellm_init.pth files survive uninstallation of the package. Removing LiteLLM does not remove the loader.
What Organizations Should Do
- Determine whether 1.82.7 or 1.82.8 ever executed, not just whether it was referenced. A lockfile or dependency entry alone is not evidence of compromise. Check package caches, CI job logs, container image layers, runner history, and installation records for the exact version. Gridinsoft's guidance is the right standard here: confirm download, install, cache, or execution.
- Hunt for the
.pthpersistence artifact. Search every Python site-packages directory forlitellm_init.pthand remove it. Also check for attacker-installed systemd services on affected hosts. This survives package removal and is the difference between a closed incident and an open one. - Remove the malicious versions and pin to a known-good release. Tenable specifies 1.82.6 or 1.83.0. Detection is available via Nessus plugin ID 304806.
- Rotate every credential the process could read, not just AI provider keys. That means cloud access keys, SSH keys, repository and package-publishing tokens, Kubernetes service account tokens, database passwords, and anything present in the runner's environment. Tenable's instruction is to treat all secrets accessible to the affected environment as exposed.
- Pin and verify security tooling in your own build pipelines. LiteLLM was compromised because its CI installed Trivy unpinned. Any tool your pipeline pulls at build time with read access to the runner is a credential-exfiltration path. Pin by digest, verify signatures, and scope runner tokens to the minimum required.
- Audit token lifetimes and revocation practice. The root enabler was an unrevoked credential. Short-lived, scoped publishing tokens with mandatory rotation would have narrowed this chain at every hop.
- Review historical images, caches, and logs even if the package is gone today. A clean current environment says nothing about what ran on March 24. Check for anomalous use of any credential that was live in that window.
Sources: Terabytes of credentials leaked in massive supply-chain attack - Ar... | LiteLLM 1.82.7 / 1.82.8 Supply Chain Compromise (GHSA-5mg7-485...<!... | Over 2,500 Organizations Impacted by LiteLLM Supply Chain Attack -... | 153GB of stolen credentials surface after LiteLLM supply ... | 2,500+ Companies and 434,000 CI/CD Pipelines Exposed in the Largest... | LiteLLM breach data shows supply chain attack impacted 2,488 firms | LiteLLM Supply Chain Attack Potentially Exposes 2,500 Companies and... | LiteLLM Breach: Check Secrets After the Supply-Chain Attack