Malicious LiteLLM Packages Raise Supply-Chain Exposure Concerns

Two malicious LiteLLM packages, versions 1.82.7 and 1.82.8, were available on PyPI for roughly 40 minutes on March 24. Threat intelligence firm CloudSEK says material linked to the operation maps potential exposure to more than 2,500 organizations, based on about 434,000 files captured by the attackers.

The figures do not establish a victim count or prove that stolen credentials were used. CloudSEK describes the material as captured loot and logs assessed as belonging to the campaign. Its public lookup lists organizations by name or domain, the number of exposed secrets and runs, and a High or Medium confidence label.

What the malicious packages collected

LiteLLM is an open-source AI gateway that connects applications to multiple model providers. The project identified the compromised versions as live from 10:39 UTC on March 24, while advising users to treat installations made up to 16:00 UTC that day as suspect. PyPI later quarantined the releases; versions 1.82.6 and 1.83.0 remain available.

The packages were built to collect environment variables, SSH keys, cloud credentials, Kubernetes tokens and database passwords, then encrypt and transmit the data to models.litellm[.]cloud, an attacker-controlled domain unrelated to the project. Unit 42 reported that the payload sought model-provider credentials held in variables including OPENAI_API_KEY and ANTHROPIC_API_KEY.

Version 1.82.8 contained litellm_init.pth, a file processed when a Python interpreter starts. That meant the code could execute whenever a Python process launched in the affected environment, even if the process did not import LiteLLM. LiteLLM also warned that an unpinned transitive dependency, such as one installed through an agent framework or orchestration tool, could have delivered the package without a direct choice by a development team.

Connection to the TeamPCP campaign

The incident is part of the broader TeamPCP software supply-chain campaign, tracked by Google as UNC6780 and linked to Aqua Security’s Trivy findings. Aqua said attackers retained access after an incomplete credential rotation, then force-pushed malicious commits to 76 of 77 trivy-action version tags, all seven setup-trivy tags, and published a malicious Trivy 0.69.4 release.

The wider compromise is tracked as CVE-2026-33634 and entered CISA’s Known Exploited Vulnerabilities catalog on March 26. The attack chain also illustrates the supply-chain risks described in supply-chain threats abusing trusted development tools amid campaigns that abuse trusted development tooling and credentials.

Published accounts differ on the immediate publication path to PyPI. CloudSEK said a poisoned build produced and published the releases; LiteLLM described a direct upload outside its official CI/CD workflow; and Unit 42 said attackers targeted PyPI publishing tokens after the Trivy breach. CloudSEK said these accounts describe successive stages: acquisition of a credential and its subsequent use. PyPA similarly said an API token exposed through the compromised Trivy dependency was used to upload the two versions.

Actions for affected teams

The FBI’s July 2 advisory, FLASH-20260702-01, warned that actors may weaponize credentials exfiltrated during the TeamPCP campaign long after the initial compromise. A static cloud key, SSH key or publishing token remains usable until it is rotated or revoked, which is why the guidance focuses on credentials rather than simply removing a package.

• Check for LiteLLM 1.82.7 or 1.82.8 installed during the March 24 audit window.
• Rotate CI/CD secrets, publishing tokens and cloud credentials that affected systems could access.
• Search GitHub organizations for repositories named tpcp-docs or docs-tpcp, and for repositories with a tpcp-docs- prefix.

Teams should also account for stolen data uploaded as release assets tagged data-<timestamp>, because an exact-name repository search can miss those indicators. The practical business implication is to treat the exposure window as a credential-risk event: establish whether affected packages reached any environment, revoke accessible long-lived secrets, and use temporary credentials where possible.