LiteLLM PyPI Versions 1.82.7–1.82.8 Compromised in Supply Chain Attack

Credential stealer exfiltrated SSH keys, cloud credentials, and Kubernetes secrets from systems running the popular LLM library.

On March 24, 2026, developers discovered malicious code inside LiteLLM packages 1.82.7 and 1.82.8 on PyPI. The library, which routes calls to more than 100 LLM providers and logs roughly 97 million downloads per month, shipped a credential-stealing payload that ran automatically on Python startup.

The attack surfaced when a developer using the library as a transitive dependency inside a Cursor MCP plugin noticed their system run out of RAM. Inspection of the wheel file revealed litellm_init.pth which is a 34 KB file that Python executes before any import. The same infostealer appeared embedded inside proxy_server.py in version 1.82.7.

How the Malware Operated

It all stemmed from the .pth file which launched a multi-stage script that:

• Collected SSH keys, AWS/GCP/Azure credentials, Kubernetes configs, git credentials, shell histories, crypto wallets, and all environment variables.
• Encrypted the data with AES + RSA.
• Exfiltrated it to https://models.litellm.cloud (not the legitimate litellm.ai domain).

It also attempted Kubernetes persistence by spawning privileged pods that mounted the host filesystem.

PyPI quarantined both versions within hours. The LiteLLM team confirmed the compromise and is working with Mandiant to investigate. They advise pinning litellm<=1.82.6 and rotating every exposed secret.

At the time of this writing, the situation is still ongoing according to a post in Hacker News.

Part of a larger campaign

The incident forms the latest link in the TeamPCP supply chain attack that began with Trivy. Attackers first poisoned Trivy’s GitHub Actions and Docker images on March 19 after incomplete credential rotation from an earlier breach. LiteLLM’s CI/CD pipeline uses Trivy for scanning, giving the attackers a path to upload the poisoned PyPI releases directly.

The window was short (under three hours) but downstream projects that pulled LiteLLM automatically (including some forks of LlamaIndex and MLflow) pulled the malware too.

Why this signals rising supply chain risk

Open-source AI tooling now sits at the center of production pipelines. A single compromised dependency can reach thousands of environments in minutes because of how popular libraries like LiteLLM appear as transitive dependencies in agent frameworks and dev tools.

The exploit succeeded because .pth files and direct PyPI uploads bypass normal code-review gates. Incomplete credential hygiene in CI/CD (the Trivy lesson) lets attackers return days later, all while AI agents auto-install packages that will amplify the blast radius.

Security teams once treated supply chain attacks as rare. Today they chain across registries, GitHub Actions to Docker to PyPI to your laptop, faster than manual audits can respond.

What Practitioners Should Do Now

1. Scan site-packages for litellm_init.pth and remove any 1.82.7 or 1.82.8 installs.
2. Rotate SSH keys, cloud credentials, Kubernetes tokens, and any secrets that lived on affected machines.
3. Pin LiteLLM (and every AI dependency) to exact versions in requirements.txt or pyproject.toml.
4. Add PyPI package signing checks and SBOM generation to CI.
5. Treat every pip install as untrusted until verified—especially inside AI agent workflows.

This incident is not just an isolated bug that we can squash and move on from. It is the predictable outcome of an ecosystem that ships code faster than it can secure the supply chain.

Builders who treat dependencies as part of their attack surface will stay ahead, and everyone else will keep rotating keys.