TeamPCP attacks the software supply chain: committed litellm to steal credentials and pivote in Kubernetes

A new wave in the war over the software supply chain again shows how fragile the open source ecosystem can be: the malicious actor known as TeamPCP has been able to violate a popular Python bookstore, litellm, and publish versions with malicious code that spread to development and production environments. Security investigators, including Endor Labs and JFrog have documented how versions 1,82.7 and 1,82.8, uploaded on 24 March 2026, contained a complex payload designed to steal credentials, move laterally within Kubernetes and establish a persistent back door.

The vector of the intrusion appears to be related to the integration of safety tools into the CI / CD pipelines: the public repo of shows use of Trivy in its flows, and that operational unit would have been exploited by the attackers to insert the malicious modification before the wheels (wheels) were published in PyPI, from where it was downloaded by projects and environments of all kinds. The compromised versions have already been removed from the official repository, but the potential damage was already under way.

From a technical point of view, the campaign uses a three-stage chain that makes it particularly dangerous. First, a credentials collector tracks SSH keys, cloud credentials, Kubernetes secrets, cryptomoneda portfolios and .env. files. That information is packaged and sent encrypted to a control and command server; according to the analysis, the file is called "tpcp.tar.gz" and is sent by an HTTPS request to models.litellm [.] cloud. In parallel, the initial load tries to climb within Kubernetes environments: if you detect a service token, use the cluster API to list nodes and deploy privileged pods that, in turn, chroot into the host file system to install a persistent dropper as a system service. Finally, that persistent service - registered as ~ / .config / sysmon / sysmon.py, the same name that appeared in previous commitments related to Trivy - regularly consult Checkmarx [.] zone / row for additional instructions or binary. A curious and frequent detail in these campaigns is the presence of a "kill switch": if the recovered URL contains youtube [.] com, the code aborts the execution.

The two malicious versions used different techniques to maximize their reach. In 182.7, the code was embedded in litellm / proxy / proxy _ server.py and was designed to run when importing that module, so any process that made import of litellm.proxy.proxy _ server activated the load without user interaction. In the following iteration, 1,82.8, the attackers were more aggressive: they added a file litellm _ init.pth at the root of the wheel. The .pth files are automatically processed by site.py when you start the Python interpreter, so that technique allows you to run code every time any Python process starts in the environment, not only when litelm is imported. In addition, the .pth invokes a subprocess in the background using subprocess.Popen, which facilitates unnoticed execution of the malicious load as a child process.

That decoded orchestrator uncovers the credentials collector and the persistence installer. The mechanism of lateral movement in Kubernetes mounts pods with privileges that make a chroot to the host system - a technique known and widely described in technical literature ( chroot) - and deploy the system service that acts as a persistent input door for subsequent payload downloads. The exfiltration strategy, the persistence by systemd and the Kill Switch pattern are consistent with other intrusions attributed to this actor.

This episode is not an isolated case: TeamPCP has shown a pattern of climbing that is part of compromising tools in CI / CD pipelines and ends up reaching production environments by supposedly reliable artifacts. According to public analysis, the campaign has affected several ecosystems - GitHub Actions, Docker Hub, npm, Open VSX and now PyPI - by expanding its capacity to act on a very diverse infrastructure and project basis. Several industry experts have warned about the domino effect: a committed tool can give keys to violate others, in a cycle that is fed back. Development organizations and teams are thus forced to react to a threat that attacks at the heart of confidence in the software supply chain.

Researchers and suppliers have published technical reports and recommendations that should be read to understand scope and mitigation. Reports such as Endor Labs and JFrog provide details of malware behavior and how it was inserted, while complementary analysis in specialized media summarizes the timing of the attack and the engagement signals.

If you manage environments using Python, automated containers or pipelines, it is a priority to review whether any of the compromised versions of litelm were downloaded. Audit facilities in virtual environments and production systems, search for suspicious files in site-packages (such as litelm _ init.pth), check Python processes in the background and check for persistent services installed under ~ / .config / sysmon are urgent initial steps. It is also necessary to inspect Kubernetes clusters by unauthorized pods or with high privileges, and to analyse network records in search of outgoing traffic to domains related to the operation, in particular models.litellm [.] cloud and Checkmarx [.] zone. No less important is to audit CI / CD pipelines to detect whether tools such as Trivy or KICS were used in the engagement window and, if appropriate, to rotate and revoke the credentials that may have been exposed.

The security community has already reacted and shared detection tools and techniques, but infrastructure managers must act quickly and cautiously: isolate committed hosts, eliminate identified persistence mechanisms, rebuild critical devices from a clean source code and rotate keys and credentials are measures that, although costly, limit the attacker's ability to move towards new goals. In parallel, it is necessary to rethink the policies of confidence in external artifacts and to strengthen the testing and monitoring in the pipelines.

The public bronze of the group itself, spread on its Telegram channel, makes it clear that its intention is to prolong and expand the campaign; and voices of the sector, such as that of Gal Nagli de Wiz, have pointed out the cyclical nature of the problem: compromising a security tool can trigger multiple commitments in cascade. For those who maintain projects and units, the lesson is painful but necessary: not to take security units as innocuous and to strengthen protection barriers around the processes that generate, pack and publish software.

In order to deepen the technical reports and the evolution of this incident, I recommend reading the analysis of Endor Labs, the report of JFrog and the pieces that summarize the case in specialized media, as well as follow the updates on the official channels where evidence and IOCs have been published. The security of the supply chain is a critical and collective issue today: protecting it requires both best technical practices and coordination between developers, project managers and security teams.