Security researchers have linked malicious LiteLLM packages hosted on PyPI to a credential-stealing operation that targeted CI/CD environments and cloud-connected systems. While the malicious releases were available for only a limited window in March, the follow-up investigation indicates the campaign’s reach may extend to thousands of organizations.
According to reporting by The Hacker News, a dataset obtained by CloudSEK—built from hundreds of thousands of captured files—maps potential exposure to more than 2,100 organizations. Importantly, the same reporting stresses that this is not a confirmed “victim count,” but an exposure estimate derived from collected evidence tied to the operation.
What the malicious LiteLLM releases did
The core issue is that two tainted LiteLLM releases reportedly contained code designed to harvest sensitive credentials from systems where they were installed. The stolen material included cloud access keys, SSH keys, Kubernetes tokens, database passwords, and other secrets stored in environment variables.
Once collected, the packages encrypted the data and sent it to an attacker-controlled destination hosted on a domain reported as unrelated to the project. This means the harm is not limited to application-level misuse; it hinges on whether credentials were accessible to the host environment at runtime.
Which LiteLLM versions were compromised
LiteLLM’s maintainers identified versions 1.82.7 and 1.82.8 as compromised. These versions were reportedly live on PyPI for about 40 minutes on March 24, starting at 10:39 UTC. PyPI later quarantined the releases, but the project advised users to treat any installation between 10:39 UTC and 16:00 UTC as suspect.
The Hacker News also notes that, upon verification on August 12 via PyPI, neither compromised version appeared in the package’s release history. Meanwhile, adjacent versions such as 1.82.6 and 1.83.0 remained available.
Why the payload could run without explicit imports
One of the compromised packages reportedly included a file named litellm_init.pth. In Python, this type of file can execute at interpreter startup, which can allow the malicious behavior to trigger as soon as a Python process begins in the affected environment—whether or not LiteLLM was explicitly imported.
In other words, teams may have installed the package and never “used” it in the usual sense, yet still have had a compromised environment capable of collecting secrets.
How exposure was estimated to reach thousands of organizations
CloudSEK’s analysis relied on a dataset constructed from roughly 434,000 files associated with the attackers’ captured loot and logs. The dataset is published as a public lookup that can be searched by name or domain and filtered by confidence.
Each record includes the organization name and domain, a count of secrets exposed, and a count of runs, along with a label such as High or Medium confidence.
High vs. medium confidence matches
A high-confidence match is described as indicating the identity of the systems each file came from, based mainly on identity signals in the CI runner environment. The reporting says the organization’s own domain must be present before a top rating is assigned. Medium-confidence results support a weaker association, for example when repository namespaces can only justify that level.
The important nuance: even where matches are high-confidence, this does not automatically prove that stolen credentials were successfully used against that organization. That’s why CloudSEK and LiteLLM both advised rotating credentials rather than waiting for definitive proof of downstream access.
Not just LiteLLM: the wider TeamPCP supply-chain context
The malicious LiteLLM incident appears to sit within a broader supply-chain compromise linked to Aqua Security’s Trivy scanner. The campaign is tracked as UNC6780. In this scenario, attackers reportedly kept access after an incomplete credential rotation and, on March 19, force-pushed malicious commits affecting many Trivy action tags and published a malicious Trivy 0.69.4 release.
At the ecosystem level, the compromise is associated with CVE-2026-33634 and was added to the CISA Known Exploited Vulnerabilities catalog on March 26. Reporting also indicates that the CVE record now lists BerriAI LiteLLM versions 1.82.7 through 1.82.8 as affected alongside Trivy components.
Credential rotation guidance and long-lived token risk
Security authorities have highlighted that credentials stolen during the exposure window may remain usable long after the initial compromise—especially if they were long-lived. The FBI’s earlier advisory (dated July 2 and referenced as FLASH-20260702-01) warned that affiliated actors could weaponize exfiltrated credentials after the fact.
As a result, the guidance focuses on rotating CI/CD secrets, published tokens, and cloud credentials that were accessible during the relevant timeframe. The rationale is straightforward: if secrets were only “reused later,” waiting for attackers to prove their use would leave organizations exposed.
A related theme in reporting from Aqua and others is the move away from long-lived tokens toward temporary alternatives, reducing the impact of credential theft.
Indicators to search in GitHub repositories
Beyond rotating secrets, the reporting includes an additional check focused on repository content. Specifically, organizations are advised to search their GitHub organizations for repositories named tpcp-docs or docs-tpcp. The FBI lists these as campaign indicators.
The reporting further notes that an Aqua advisory for the CVE mentions the malware created repositories with a tpcp-docs prefix and uploaded stolen data as a release asset tagged with a name pattern such as data-<timestamp>. Because of this naming behavior, relying on one exact string match may miss some artifacts.
How the malicious packages reached PyPI remains disputed
Different accounts disagree on the precise path the tainted releases took to reach PyPI. CloudSEK’s report describes the poisoned build producing and publishing the releases. LiteLLM’s incident report points instead to a direct PyPI upload that bypassed its normal CI/CD workflow. Unit 42 describes attackers targeting PyPI publishing tokens obtained following the Trivy breach.
CloudSEK argues these descriptions represent different stages in a single chain rather than competing explanations. The reporting also indicates that PyPA’s advisory describes a similar sequence: an exposed API token through the compromised Trivy dependency, followed by the use of that token to upload the two versions.
What organizations should do now
Even though estimates differ across analyses, the immediate risk remains: malicious LiteLLM versions were installed in real environments, and credentials available at runtime may have been harvested. To reduce risk, organizations evaluating potential exposure should take three practical steps:
- Check for LiteLLM 1.82.7 or 1.82.8 installations within LiteLLM’s March 24 audit window (10:39 to 16:00 UTC).
- Rotate any secrets those systems could access, especially cloud keys, SSH keys, Kubernetes tokens, and database passwords.
- Search GitHub organizations for repositories named tpcp-docs or docs-tpcp, and consider nearby naming variations that match the campaign’s release asset pattern.
Where possible, also review CI runner configurations and token lifetimes to limit future exposure. If you use long-lived credentials, treat this event as a strong signal to tighten controls and adopt short-lived, least-privilege access.
Conclusion
The disclosure around malicious LiteLLM shows how quickly a supply-chain compromise can move from a compromised dependency to credential theft across environments. Although the tainted PyPI packages were present for a short period, the mechanics of the payload—combined with access to environment variables and other secret stores—can create long-lasting risk.
With public exposure lookups available and clear steps issued for incident response, organizations are encouraged to validate whether they installed the affected versions during the audit window, rotate credentials promptly, and check for campaign indicators in GitHub.
Source: https://thehackernews.com/2026/08/malicious-litellm-releases-tied-to.html
