When a Python Package Steals Your Whole Server: The litellm Supply Chain Attack

TL;DR — In March 2026 an attacker hijacked a litellm maintainer's PyPI account and published malicious 1.82.7/1.82.8 builds. Version 1.82.8 shipped a .pth file that ran on every Python startup — no import needed — and exfiltrated SSH keys, environment variables, AWS/GCP/Azure/K8s credentials, and crypto wallets to a lookalike domain (litellm.cloud, not the official litellm.ai). Every server running pip install was a target. Lock, audit, and isolate your secrets.

What actually happened, per the official report

From the litellm team's official post in BerriAI/litellm issue #24518:

• The maintainer's PyPI account (krrishdholakia) was hijacked by an attacker using the handle teampcp.
• Versions 1.82.7 and 1.82.8 were uploaded directly to PyPI and never went through the official GitHub CI — official GitHub releases only went up to v1.82.6.dev1.
• The malicious exfiltration domain litellm.cloud (official is litellm.ai) was registered via Spaceship on 2026-03-23, just hours before the packages appeared.

How the attack worked

Version 1.82.8 contained a 34,628-byte litellm_init.pth file inside site-packages. Per Python's own docs, .pth files execute automatically when the interpreter starts — so the payload ran without anyone importing litellm. It was double base64-encoded (invisible to naive source grep) and collected:

| What was stolen | Example files | |---|---| | Keys and secrets | printenv (all API keys), ~/.ssh/id_rsa, ~/.aws/credentials, ~/.kube/config | | Everyday logins | ~/.git-credentials, ~/.npmrc, ~/.netrc, ~/.docker/config.json | | History and wallets | ~/.bash_history, ~/.zsh_history, Ethereum keystore, Solana, Ripple | | CI/CD and SSL | terraform.tfvars, .gitlab-ci.yml, Jenkinsfile, keys in /etc/ssl/private/ |

Data was encrypted with AES-256-CBC, the session key wrapped with a hardcoded 4096-bit RSA public key, and everything POSTed via a single curl to https://models.litellm.cloud/.

Why this matters if you just run a small online business

Attackers don't pick targets here — anyone running pip install is in scope. If a store backend, a Telegram bot, or any small service on your server installs Python packages, that same server holds your payment gateway keys, SMTP creds, SSH keys, and database passwords. One malicious package = full handover of all of it.

The litellm team worked with Google's mandiant.security team, and the package was fully removed from PyPI. The current version on PyPI is 1.106.0; the malicious 1.82.7/1.82.8 builds no longer exist.

Prevention checklist

• [ ] Pin every dependency with a lockfile (uv.lock or exact-pinned requirements.txt) — unpinned installs are Russian roulette
• [ ] Run pip-audit (current version 2.10.1) against your project environment on a schedule
• [ ] Move secrets out of plain .env files into a secret manager, or at minimum chmod 600 them; never commit them
• [ ] Before upgrading sensitive packages, compare the official GitHub release with the PyPI version — if it never passed CI, alarm bells
• [ ] Be suspicious of brand-new domains in network errors — this attack's only tell was litellm.cloud vs litellm.ai
• [ ] Deploy production from the official Docker image with pinned dependencies (Docker image users were unaffected in this incident)

Takeaway

Supply chain attacks like this bypass even hardened servers because they target the install step, not runtime. Never treat pip install as a safe operation — every package is code that will soon run with your privileges. Lockfiles + periodic audits + secret management would have reduced this incident's damage to near zero.

Q: How do I know if I was compromised?

Per the litellm team's official guidance: look for litellm_init.pth in your site-packages directory. If present, rotate all credentials that lived in environment variables, SSH, cloud configs, and databases. If you used the official Docker image, the team confirmed you were not affected.

Q: Was only version 1.82.8 affected?

No — 1.82.7 also carried a payload, but it only triggered on import litellm.proxy. 1.82.8 was worse: the .pth file fired on every Python startup. The team noted other versions still needed auditing.

Q: What's a safe alternative to litellm?

The real fix isn't swapping packages — it's locking dependencies, auditing before upgrades, and isolating secrets. If you do want an alternative, verify the official repo and CI-signed releases, not just star counts.

Sources

• https://github.com/BerriAI/litellm/issues/24512
• https://github.com/BerriAI/litellm/issues/24518
• https://news.ycombinator.com/item?id=47501729
• https://pypi.org/project/pip-audit/