Two malicious LiteLLM releases sat on PyPI for about 40 minutes in March carrying credential-stealing code capable of harvesting cloud keys, SSH keys, Kubernetes tokens, database passwords, and other secrets from systems that installed them.
Threat intelligence firm CloudSEK now says a dataset it obtained, built from roughly 434,000 files the attackers captured, maps potential exposure to more than 2,500 organizations.
Those totals are not a victim count. CloudSEK told The Hacker News the material came from confidential intelligence sources and consists of captured loot and log files it assessed as belonging to the campaign, not data gathered from the organizations it names. The files were taken, in other words.
CloudSEK has published the dataset as a public lookup, searchable by name or domain and filterable by confidence. Each row gives an organization’s name and domain, a count of secrets exposed, a count of runs, and a label reading High or Medium.
What a high-confidence match asserts is whose systems each file came from. That verdict keys on identity signals in the captured CI runner environment, chiefly host identity and legitimate committer domains, and the organization’s own domain has to appear before a match earns the top rating.
Repository namespaces support only a medium-confidence call. NVIDIA, Cisco, Deloitte, Volkswagen, FedEx, Siemens, and X Corp are among the entries, and none of that establishes that stolen credentials were used, which is why both CloudSEK and LiteLLM tell affected parties to rotate rather than wait for proof.
LiteLLM is an open-source AI gateway used to connect applications with multiple model providers. The project identified versions 1.82.7 and 1.82.8 as compromised and said they were live on March 24 from 10:39 UTC for about 40 minutes before PyPI quarantined them, though it tells users to treat any install that day up to 16:00 UTC as suspect.
The Hacker News confirmed via PyPI on August 12 that neither version appears in the package’s release history, while 1.82.6 and 1.83.0 remain available.
The FBI warned in a July 2 advisory, FLASH-20260702-01, that affiliated actors are likely to weaponize credentials exfiltrated during the TeamPCP campaign long after the initial compromise. It told organizations to rotate CI/CD secrets, publishing tokens, and cloud credentials accessible during the relevant exposure windows.
A long-lived secret copied during that window, a static cloud key, an SSH key, or a publishing token, remains usable unless it has since been rotated or revoked. That is why the bureau’s guidance is scoped to credentials rather than to the package, and why both it and Aqua tell teams to move away from long-lived tokens toward temporary ones.
Version 1.82.8 included a file named litellm_init.pth that Python processes at interpreter startup, so it ran whenever a Python process started in that environment, whether or not anything imported LiteLLM.
The compromised packages were designed to collect environment variables, SSH keys, cloud credentials, Kubernetes tokens, and database passwords before encrypting and sending stolen data to models.litellm[.]cloud, an attacker-controlled domain unrelated to the project.
Unit 42’s campaign analysis records the payload reading environment variables that hold model API keys, including OPENAI_API_KEY and ANTHROPIC_API_KEY.
That behavior inverts the usual triage question. Whether a team knowingly uses LiteLLM matters less than whether anything on the host installed it, and the project’s advisory notes that an unpinned transitive dependency, including one pulled in by an agent framework or orchestration tool, could deliver it without anyone choosing it.
The LiteLLM incident sits inside a wider TeamPCP supply-chain campaign linked to Aqua Security’s Trivy scanner. Google tracks TeamPCP as UNC6780. Aqua said attackers retained access after an incomplete credential rotation and, on March 19, force-pushed malicious commits to 76 of 77 trivy-action version tags and all seven setup-trivy tags while publishing a malicious Trivy 0.69.4 release.
The ecosystem compromise is tracked as CVE-2026-33634, added to CISA’s Known Exploited Vulnerabilities catalog on March 26. The Hacker News confirmed on August 12 that the CVE record now lists BerriAI LiteLLM 1.82.7 through 1.82.8 as affected alongside the Trivy components.
Exactly how the malicious LiteLLM releases reached PyPI was disputed across the published accounts. CloudSEK’s report said the poisoned build produced and published the releases, LiteLLM’s own incident report pointed to a direct PyPI upload that bypassed its official CI/CD workflow, and Unit 42 described attackers targeting PyPI publishing tokens after the Trivy breach.
Asked about the discrepancy, CloudSEK pushed back. “These are different stages of the same attack chain, not competing explanations,” the company told The Hacker News. Its evidence covers how the credential was obtained, while the LiteLLM and Unit 42 findings cover how it was then used.
PyPA’s advisory for the malicious releases describes the same sequence: an API token exposed through the compromised Trivy dependency and then used to upload the two versions. BerriAI had not responded to questions about which account its own forensics support at the time of writing.
Attribution inside the dataset runs through two independent checks, CloudSEK said. An index assigns each file using CI identity variables, and a separate ownership gate re-derives ownership from the fetched logs and can override that assignment. “If they disagree, the report is withheld,” the company said, and the final verdict takes the lower of the two confidence levels.
The 434,000 figure counts captured files and exfiltration events rather than distinct pipelines, runs, or jobs. CloudSEK said one captured file is roughly one job execution, but it does not present the total as unique jobs without independent deduplication and verification.
The company declined to discuss pre-publication notifications to the named organizations, and would not say whether any disputed its inclusion.
The campaign’s downstream impact is confirmed even if CloudSEK’s scale figures are not. Checkmarx said credentials obtained through the Trivy attack enabled unauthorized access to its GitHub repositories and the publication of malicious artifacts. Mercor said it was affected by malicious LiteLLM versions and contained unauthorized activity.
CERT-EU separately assessed with high confidence that a European Commission AWS account was compromised through the Trivy supply-chain attack, with about 91.7 GB of compressed data exfiltrated.
Organizations assessing exposure should take three steps:
- Check for LiteLLM 1.82.7 or 1.82.8 installations during LiteLLM’s March 24 audit window of 10:39 to 16:00 UTC.
- Rotate any secrets those systems could access.
- Search their GitHub organizations for repositories named tpcp-docs or docs-tpcp, which the FBI lists as campaign indicators. Aqua’s advisory for the CVE notes the malware created these with a tpcp-docs- prefix and uploaded stolen data as a release asset tagged data-
, so an exact-name search can miss them.
Found this article interesting? Follow us on Google News, Twitter and LinkedIn to read more exclusive content we post.
