How a Supply‑Chain Attack Compromised LiteLLM and Stole Every Credential

On March 24, two malicious releases of the popular Python library LiteLLM (versions 1.82.7 and 1.82.8) were published to PyPI. Each package contains a crafted .pth file (named litellm_init.pth) that is automatically processed by Python’s site module on interpreter start, allowing code execution without importing the library.

Attack Mechanism

The .pth file executes a one‑liner that spawns a subprocess via subprocess.Popen. The subprocess runs a base64‑encoded payload which performs three nested base64 decodings and then:

Recursively scans directories such as /home, /opt, /srv, /var/www, /app, /data and /tmp for sensitive files (SSH private keys, cloud provider credentials, Kubernetes secrets, .env files, database passwords, cryptocurrency wallets, etc.).

Generates a random 32‑byte AES‑256 session key and encrypts the harvested data with it.

Encrypts the session key with the attacker’s 4096‑bit RSA‑OAEP public key, packages the ciphertext and the encrypted session key into tpcp.tar.gz, and POSTs the archive to the counterfeit domain http://models.litellm.cloud.

If the victim runs inside a Kubernetes cluster, the payload also creates a privileged pod that spreads laterally across nodes.

Persistence Backdoor

Beyond the credential harvester, the malicious code installs a persistent backdoor:

Writes ~/.config/sysmon/sysmon.py and registers a systemd user service ( ~/.config/systemd/user/sysmon.service).

The service runs every 50 minutes, contacts http://checkmarx.zone for new commands, downloads them to /tmp/pglog, and executes them after a five‑minute delay to evade sandbox analysis.

The backdoor remains active even after the LiteLLM package is uninstalled.

Impact and Distribution

The attack does not require explicit imports of LiteLLM; any environment that installs the library—directly or as a transitive dependency (e.g., DSPy, MLflow, Open Interpreter, and over 2,000 other packages)—is vulnerable. Mandiant reports more than 1,000 SaaS environments already compromised, with estimates that the number could reach 10,000.

Supply‑Chain Compromise Origin

The supply‑chain breach began when the security‑scanning tool Trivy was compromised on March 19. The attacker group (identified as TeamPCP) stole the PyPI publishing token for LiteLLM and used it to upload the poisoned wheels on March 24. After the community opened a GitHub issue, the attackers flooded the discussion with 88 spam comments from 73 stolen accounts and later closed the issue using a compromised maintainer account.

Detection and Remediation

To verify whether a malicious version is installed, run the following commands in every Python environment (virtualenv, Conda, system‑wide):

pip show litellm
pip3 show litellm

If you use the uv installer, locate the injected .pth file: find ~/.cache/uv -name "litellm_init.pth" Safe version: litellm==1.82.6. Versions 1.82.7 and 1.82.8 are compromised.

Remediation steps:

Uninstall the package and purge pip caches: pip uninstall litellm && pip cache purge If uv was used, delete its cache: rm -rf ~/.cache/uv Remove the persistence files:

rm -rf ~/.config/sysmon/ ~/.config/systemd/user/sysmon.service

Rotate all credentials (SSH keys, cloud provider keys, Kubernetes kubeconfig, .env API keys, database passwords, cryptocurrency wallets).

Audit Kubernetes namespaces for secret access and delete any node-setup-* pods created by the backdoor.

A self‑contained detection script that checks package versions, searches for the malicious .pth file, detects the backdoor, monitors suspicious network connections, and scans Kubernetes clusters is available at:

https://gist.github.com/sorrycc/30a765b9a82d0d8958e756b251828a19

This incident highlights the hidden attack surface of Python .pth files, which can execute arbitrary code on interpreter start without any explicit import, making them a blind spot for many developers.