On March 24, 2026, while AI developers were still coding, the LiteLLM package on PyPI was quietly “poisoned.” LiteLLM—a Python open-source library with a staggering monthly download count of 97 million—had its PyPI repository maliciously tampered with in the early hours of the morning. Two compromised versions (1.82.7 and 1.82.8) were silently published. Within just three hours, tens of thousands of development environments and enterprise systems may have been exposed to data leakage risks. Unlike ordinary attacks, this incident was not an isolated case of malicious injection; rather, it was a meticulously orchestrated chain attack by the hacker group TeamPCP.

SlowMist’s self-developed Web3 threat intelligence and dynamic security monitoring tool, MistEye, also pushed relevant threat intelligence alerts to affected customers immediately upon detection.

The root cause of this LiteLLM attack did not lie in any vulnerability within the library itself, but rather in the open-source security scanner Trivy—used in LiteLLM’s CI/CD pipeline—which had already been compromised. Tracing the attack timeline: On March 19, TeamPCP tampered with Trivy’s GitHub Action tag, injecting malicious code; on March 23, attackers breached Checkmarx KICS, a security scanning tool, paving the way for the next stage; and on March 24, LiteLLM’s CI/CD pipeline executed the compromised version of Trivy, resulting in the theft of its PyPI publishing token. Attackers exploited this token to bypass normal publishing procedures and directly push the two malicious versions to PyPI—successfully “poisoning” a core AI dependency library.

The exposure of this attack unfolded with dramatic irony: The attackers intended to operate stealthily—but inadvertently introduced a flaw while writing their own malicious code. Specifically, the litellm_init.pth file embedded in version 1.82.8 automatically executes every time a Python process starts and recursively triggers itself via subprocesses, causing FutureSearch engineers’ test machines to exhaust memory and crash. This accidental bug prematurely exposed what could otherwise have remained hidden for days—or even weeks—with potentially catastrophic consequences.

TeamPCP’s malicious code targeting LiteLLM adopted a multi-stage execution strategy—offering high concealment, broad impact scope, and robust persistence and lateral movement capabilities—far exceeding the damage potential of typical supply-chain attacks.

Stage One: Information Collection
The malicious script systematically scans all sensitive data on infected hosts, covering an exceptionally wide range: developers’ SSH private keys, Git configurations, shell history, enterprise cloud provider credentials (AWS/GCP/Azure), Kubernetes configurations, database passwords—and even cryptocurrency wallet files and mnemonic phrases. Notably, as a unified gateway for calling various large language model APIs, LiteLLM commonly stores API keys from multiple LLM providers. Once compromised, it effectively grants attackers unrestricted access to an organization’s entire AI infrastructure.

Stage Two: Encrypted Exfiltration
All collected data is encrypted using AES-256-CBC, with the session key protected by a 4096-bit RSA public key. The encrypted payload is then packaged into a tar archive and exfiltrated to the attacker-controlled fake domain models.litellm.cloud—a domain registered just one day before the attack and entirely unrelated to LiteLLM’s official infrastructure, making it highly deceptive. According to disclosures, attackers have already stolen approximately 300 GB of compressed credential data, comprising roughly 500,000 sensitive credentials.

Stage Three: Persistence and Lateral Movement
This final stage constitutes the most dangerous long-term consequence of the attack. Locally, the malware creates a backdoor script named sysmon.py in the user’s home directory and registers it as a systemd service for auto-start—meaning the backdoor persists even after LiteLLM is uninstalled. If a Kubernetes environment is detected, attackers leverage service account tokens to deploy privileged Pods across all cluster nodes, enabling full-network propagation and transforming infection on a single host into a cluster-wide security crisis. Attackers also attempted to cover their tracks by flooding GitHub issue threads with malicious bot spam and hijacking maintainer accounts to close issues.

Currently, PyPI has withdrawn the compromised versions and lifted the quarantine. The LiteLLM maintainers are handling follow-up remediation—but the aftermath of this attack remains far from resolved. First, cleaning persistent backdoors poses a serious challenge: some users may mistakenly believe the risk is eliminated simply by uninstalling LiteLLM, unaware that the backdoor continues operating silently in the background. Second, the ripple effects of credential leakage are severe—the 500,000 stolen credentials could trigger a “domino effect” across interconnected systems. Third, there is substantial diffusion risk along the dependency chain: LiteLLM is referenced by over 2,000 packages—including DSPy, MLflow, and Open Interpreter—meaning many developers indirectly pulled in the malicious versions through other tools they use.

This LiteLLM attack inevitably evokes memories of the Trust Wallet security incident. Moreover, in this LiteLLM attack, cryptocurrency wallet files and mnemonic phrases were explicitly targeted for theft—and the attackers demonstrated proven capabilities for long-term dormancy and lateral movement. In fact, TeamPCP previously mocked security vendors publicly, claiming they “can’t even protect their own supply chains,” and declared intentions to conduct prolonged commercial espionage. The LiteLLM attack is merely one component of their systematic infiltration of the open-source ecosystem.

In response to this attack and its lingering consequences, both individual developers and enterprises must act immediately:
1. Immediately investigate for infection: If using LiteLLM v1.82.7 or v1.82.8, uninstall immediately and clear all caches.
2. Rotate all sensitive credentials comprehensively, including SSH keys, cloud provider credentials (AWS/GCP/Azure), database passwords, API keys—and especially cryptocurrency wallet private keys and mnemonic phrases.
3. Enforce strict dependency management: Pin LiteLLM to v1.82.6 or earlier secure versions, and strengthen CI/CD pipeline security.

The LiteLLM supply-chain attack not only exposes the fragility of the open-source ecosystem but also serves as a stark reminder: In today’s era of rapid AI advancement, the security of core dependency libraries directly determines the stability of the entire ecosystem. Only by confronting supply-chain security head-on—proactively identifying vulnerabilities and building comprehensive defense systems—can we avoid similarly devastating losses and safeguard our data and assets.

[SlowMist Technology]