← Back to Blog

litellm 1.82.8 Supply Chain Attack on PyPI (March 2026)

2026-03-24 • Updated March 30, 2026
By Callum McMahon

A compromised release steals credentials and spreads to Kubernetes clusters. First reported to PyPI by FutureSearch.

Update (12:30 UTC): version 1.82.7 is also compromised, in addition to 1.82.8

Update (13:03 UTC): The public GitHub issue has been closed as "not planned" by the owner, and is spammed by hundreds of bots to dillute the discussion. The author of litellm have been very likely fully compromised.

Update (20:15 UTC): The compromised versions have been yanked, and the PyPI quarantine has been lifted. The package maintainers are handling the fallout. Fortunately, no FutureSearch users were affected.

Follow-up: We published a follow-up analysis and an interactive checker tool to help you determine if your packages were affected.

At 10:52 UTC on March 24, 2026, litellm version 1.82.8 was published to PyPI. The release contains a malicious .pth file (litellm_init.pth) that executes automatically on every Python process startup when litellm is installed in the environment. No corresponding tag or release exists on the litellm GitHub repository — the package appears to have been uploaded directly to PyPI, bypassing the normal release process.

We discovered it when the package was pulled in as a transitive dependency by an MCP plugin running inside Cursor. The .pth launcher spawns a child Python process via subprocess.Popen, but because .pth files trigger on every interpreter startup, the child re-triggers the same .pth — creating an exponential fork bomb that crashed the machine. The fork bomb is actually a bug in the malware.

What the malware does

The payload operates in three stages:

  1. Collection. A Python script harvests sensitive files from the host: SSH private keys and configs, .env files, AWS / GCP / Azure credentials, Kubernetes configs, database passwords, .gitconfig, shell history, crypto wallet files, and anything matching common secret patterns. It also runs commands to dump environment variables and query cloud metadata endpoints (IMDS, container credentials).

  2. Exfiltration. The collected data is encrypted with a hardcoded 4096-bit RSA public key using AES-256-CBC (random session key, encrypted with the RSA key), bundled into a tar archive, and POSTed to https://models.litellm.cloud/ — a domain that is not part of legitimate litellm infrastructure.

  3. Lateral movement and persistence. If a Kubernetes service account token is present, the malware reads all cluster secrets across all namespaces and attempts to create a privileged alpine:latest pod on every node in kube-system. Each pod mounts the host filesystem and installs a persistent backdoor at /root/.config/sysmon/sysmon.py with a systemd user service. On the local machine, it attempts the same persistence via ~/.config/sysmon/sysmon.py.

What you should do

Check whether you're affected. If you installed or upgraded litellm on or after March 24, 2026, check for version 1.82.8: run pip show litellm, inspect uv caches (find ~/.cache/uv -name "litellm_init.pth"), and check virtual environments in CI/CD.

Remove the package and purge caches. Delete litellm 1.82.8 from any affected environment. Purge your package manager cache (rm -rf ~/.cache/uv or pip cache purge) to prevent re-installation from cached wheels.

Check for persistence. Look for ~/.config/sysmon/sysmon.py and ~/.config/systemd/user/sysmon.service. If running in Kubernetes, audit kube-system for pods matching node-setup-* and review cluster secrets for unauthorized access.

Rotate credentials. Assume any credentials present on the affected machine are compromised: SSH keys, cloud provider credentials (GCP ADC, AWS access keys, Azure tokens), Kubernetes configs, API keys in .env files, and database passwords.

We have reported this to PyPI (security@pypi.org) and emailed the litellm maintainers directly. The community is tracking the issue at litellm #24512.

Addendum: How we encountered this

We encountered this while working our product, futuresearch.ai/app, which gives users a team of researchers. We use litellm to let us use models from a wide range of providers, letting us strike the best balance between quality, speed and cost. One of our engineers noticed the problem and used Claude Code to help root-cause it. The damage to us was minimal, and no user data was leaked.