LiteLLM, an AI suite with nearly 100 million monthly downloads, suffers a supply chain attack, compromising its encrypted wallets and SSH keys (including emergency remediation steps).

LiteLLM, an open-source AI suite with 97 million monthly downloads, was found to have been attacked by the supply chain on the 24th. Two compromised versions (v1.82.7 and v1.82.8) were infected with malicious code that could systematically steal almost all sensitive information such as encrypted wallets, SSH keys, and cloud credentials.

SlowMist Technology's cybersecurity chief, 23pds, cited the news on X this morning and issued a serious warning.

Who discovered it? Who was the attacker?

FutureSearch engineer Daniel Hnyk was the first professional to expose the vulnerability. He and Callum McMahon detected the abnormal behavior when LiteLLM was introduced as an indirect dependency of the Cursor MCP add-in, and then began reverse engineering .

It was later discovered that the attackers were the hacker group TeamPCP . This group had previously compromised the CI/CD pipeline of the well-known open-source security scanner Trivy, thereby obtaining the PyPI account credentials of the LiteLLM maintainer, and subsequently uploaded two malicious versions with backdoors.

Three-stage attack mechanism

The execution of malicious code consists of three interconnected stages:

Stage 1 — Credential Harvesting : After installation, a malicious `.pth` file (`litellm_init.pth`) executes automatically every time a Python program starts, without requiring any `import` directives to trigger it. The stolen list includes SSH keys, `.env` files (containing API keys), AWS/GCP/Azure cloud credentials, Kubernetes configurations, Git credentials, shell command history, and cryptocurrency wallet files and database passwords.

Stage 2 — Data Leakage : All stolen data was encrypted with a hard-coded 4096-bit RSA public key and AES-256-CBC, packaged into a tar archive, and sent via a POST request to `https://models.litellm.cloud/` — this domain has no connection with the official LiteLLM website and is a leak endpoint set up by the attackers themselves.

Stage 3 — Lateral Movement and Persistence : If the machine possesses a Kubernetes token, the malware reads the secrets of all namespaces and deploys a privileged `alpine:latest` Pod on each kube-system node, mounting the host file system. Simultaneously, it installs a persistent backdoor in `/root/.config/sysmon/sysmon.py` and establishes a systemd user service to ensure survival after a reboot.

Event Timeline

The entire incident unfolded rapidly in less than 10 hours:

– March 24, 10:52 UTC : v1.82.8 uploaded to PyPI
– 12:30 UTC : v1.82.7 confirmed to be compromised as well. – 13:03 UTC : The notification issue on GitHub was mistakenly flagged as spam by a bot and marked as "not planned," delaying the public warning. – 20:15 UTC : The compromised version has finally been removed from PyPI, and the quarantine has been lifted.

From the time the malicious version was launched to its removal, it had approximately 9 hours of exposure time.

Why are crypto developers considered a high-risk group?

LiteLLM is one of the most popular AI model agent suites currently available, and many crypto and DeFi projects rely on it as their model routing layer for their AI agent infrastructure. This attack directly put cryptocurrency wallet files on the theft list, meaning that any developer running LiteLLM on the same machine and holding crypto assets is at direct risk.

Even more alarming is the attack vector itself: by introducing indirect dependencies through the MCP add-on, developers may not even realize they've installed LiteLLM. This reveals a structural security blind spot in the AI ​​Agent toolchain: the more complex the dependency chain of the add-on ecosystem, the wider the attack surface for supply chain attacks.

Emergency Repair Steps

Developers who have installed LiteLLM should immediately perform the following checks:

1. Use `pip show litellm` to confirm the current version; v1.82.7 or v1.82.8 is a damaged version.
2. Remove the affected version and clear the pip cache.
3. Check if `~/.config/sysmon/sysmon.py` and `sysmon.service` exist.
4. Kubernetes Environment: Scan the `kube-system` namespace for `node-setup-*` Pods.
5. All SSH keys, cloud credentials (AWS/GCP/Azure), API keys, and encrypted wallet private keys must be assumed to have been compromised and rotated immediately.