LiteLLM PyPI Package Compromised in TeamPCP Supply‑Chain Attack

LiteLLM PyPI Infection: TeamPCP Hits a Widely Used LLM Gateway

A major supply-chain incident has rocked the open-source ecosystem once again as the TeamPCP hacking group targeted the popular LiteLLM Python package on PyPI. LiteLLM serves as a gateway to multiple large language model providers through a single API, making it a widely used tool for developers building AI-enabled applications. The library’s reach is immense, with millions of downloads daily and tens of millions more in recent weeks, underscoring how a compromised supply chain can have cascading effects across countless projects and deployments.

Research into the incident shows that threat actors pushed two malicious LiteLLM releases—versions 1.82.7 and 1.82.8—onto PyPI. These counterfeit builds carried a hidden infostealer designed to harvest a broad set of sensitive data from infected machines. The offensive campaign is attributed to TeamPCP, the same group behind other high-profile supply-chain compromises tied to Aqua Security’s Trivy vulnerability scanner and related ecosystem interventions.

In the code analysis, the malicious payload was injected into theLiteLLM module’s internal script, specifically litellm/proxy/proxyserver.py. The payload is encoded in base64 and decoded at runtime when the package is imported, triggering the data-stealing routines without requiring any explicit user action beyond installing the compromised package. The more aggressive variant, 1.82.8, introduced a persistence mechanism that leverages a Python startup hook: a .pth file named litellminit.pth is installed so that Python will execute malicious code at interpreter startup, even if LiteLLM itself is not actively used in a session.

Security researchers describe a three-stage attack once the payload runs. First, credentials are harvested—ranging from SSH keys and cloud provider tokens to Kubernetes service tokens, environment files (.env variants), database credentials, TLS private keys, and even cryptocurrency wallet data. Second, the attacker attempts lateral movement by exploiting Kubernetes environments, deploying privileged pods across nodes to extend reach within clusters. Third, a persistent backdoor is installed via systemd, enabling ongoing access and enabling the operator to pull additional payloads as needed. Exfiltrated data is encrypted and sent to attacker-controlled infrastructure, where it can be cataloged and weaponized by the operators.

The broader campaign is framed by the attackers’ aim to exfiltrate credentials and shift the data to a dictated infrastructure. A key component of the operation is a separate “TeamPCP Cloud Stealer” module, designed to steal credentials and other sensitive information from infected devices, bundled into an encrypted archive named tpcp.tar.gz. The stolen data is funneled to attacker-controlled domains, including a cloud resource under a domain associated with the LiteLLM operation.

Notably, the campaign is not limited to a single region. Endor Labs describes additional Kleptocratic behavior, including a wiper operation aimed at Iran-targeted Kubernetes environments and a separate CanisterWorm-like backdoor that can persist on devices in other regions. The breadth of TeamPCP’s activity—spanning Kubernetes clusters, cloud tokens, and local credential stores—reflects a broader pattern seen in modern supply-chain intrusions: attackers aim for broad reach and durable footholds, then monetize the access through credential harvesting and data exfiltration.

Initial reports place the scale of the data exfiltration at roughly 500,000 infected devices, with many duplicates among the exfiltrated payloads. Independent verification of these figures remains challenging, and researchers caution that the numbers may be inflated by duplicated data sources or partial payloads. The fact remains clear: the attack demonstrates how a single compromised package can serve as a gateway to a wide array of sensitive information, from cloud tokens to Kubernetes secrets, and how persistence mechanisms can ensure ongoing access even after the initial incident is discovered.

In response to the discovery, the two malicious LiteLLM versions were removed from PyPI. A clean, safe release—version 1.82.6—has been identified as the latest legitimate iteration. This development underscores a critical reality for developers and organizations relying on third-party packages: even widely trusted dependencies can become vectors for advanced threats, and the integrity of supply chains depends on vigilant monitoring, rapid response, and robust credential hygiene.

The LiteLLM supply-chain attack also reinforces broader lessons about the cybersecurity landscape today. Attackers are leveraging familiar tools and legitimate development workflows to blur the lines between legitimate software updates and malicious injections. By embedding payloads in the installation process and using startup-time execution, they increase the likelihood that their code will run in diverse environments—CI pipelines, local development machines, and production servers alike. The result is a deceptive resilience: even when a malicious release is discovered and removed, the damage potential can persist in the form of stolen tokens, secret keys, and misconfigured permissions that outlive the compromised package.

This episode also highlights the ongoing tension between speed, openness, and security in modern software ecosystems. While rapid distribution of software and easy access to powerful AI tools are core strengths, they can also create attack surfaces that adversaries are eager to exploit. As teams continue to rely on a growing constellation of open-source components and cloud integrations, the emphasis on credential management, secret rotation, and continuous monitoring becomes increasingly essential. The reality is that even established, popular libraries can be weaponized, and operators behind such campaigns are increasingly adept at blending malicious code into legitimate software streams.

As organizations review their environments in the wake of this incident, the focus remains on confirming whether affected deployments still harbor traces of the malicious variants, and on ensuring that any credentials or secrets exposed during the attack are rotated or revoked. The broader message is clear: supply-chain security is not a one-time fix but an ongoing discipline that requires visibility across software supply chains, vigilant artifact management, and proactive credential hygiene to mitigate cascading risks when a trusted component is compromised.