LiteLLM Supply Chain Attack: What Happened and What to Do

On March 24, 2026, attackers published two malicious versions of LiteLLM to the Python Package Index. The versions, litellm==1.82.7 and litellm==1.82.8, were live for approximately three hours before being pulled, but in that window they accumulated roughly 119,000 installs. If you run LiteLLM in any environment, this article covers what happened, what was stolen, and what you need to do.

Background: How This Happened

LiteLLM is a Python proxy layer that lets developers call 100+ LLM APIs through a single OpenAI-compatible interface. It had approximately 95 million monthly downloads at the time of the attack, and industry estimates put it in roughly 36% of cloud environments running AI inference workloads. That makes it an extremely high-value target.

The attack chain started five days earlier with the Trivy supply chain compromise on March 19. TeamPCP used malicious code planted in Trivy’s build pipeline to exfiltrate credentials from CI/CD environments that ran Trivy. Among those credentials were PyPI publishing tokens belonging to LiteLLM’s maintainers. With valid publishing tokens, TeamPCP could push new versions of LiteLLM to PyPI as if they were legitimate releases.

What the Malicious Versions Contained

The payload was embedded in two locations:

proxy_server.py, The core proxy server file was modified to run credential exfiltration on startup. Any environment that imported or started the LiteLLM proxy would trigger the payload silently alongside normal startup.

A .pth file, Python path configuration files in .pth format execute automatically when the Python interpreter starts, before any user code runs. This is a known technique for achieving persistence: even if someone audited the LiteLLM source and missed the proxy_server.py change, the .pth file would still run on every Python process in the environment.

The combination of both vectors means the payload ran reliably across different usage patterns, whether you were running the LiteLLM proxy, importing the library directly, or just had it installed in a shared Python environment.

What Was Stolen

Based on analysis of the malicious releases, the exfiltration scope was broad, and the payload targeted:

• Environment variables, All environment variables in the process context
• API tokens, OpenAI, Anthropic, and other LLM provider keys (commonly stored in environment variables for LiteLLM configuration)
• SSH keys, Private keys from ~/.ssh/
• Git and CI/CD secrets, .git-credentials, GitHub tokens, GitLab tokens, CircleCI tokens, and similar
• Cloud provider credentials, AWS credentials (~/.aws/credentials), GCP service account keys, Azure service principal secrets
• Database credentials, Connection strings and passwords from common configuration locations
• Kubernetes secrets, Service account tokens and config files from ~/.kube/config
• SSL/TLS private keys, Certificate private keys from common paths

This is essentially a full credential sweep targeting everything in reach. If it existed in or near the environment where LiteLLM was installed, the payload tried to exfiltrate it.

The Scale of Exposure

119,000 installs in three hours is a large number, but it understates the risk in two ways.

First, LiteLLM is commonly installed in shared environments, development containers, staging clusters, CI systems, where a single install can expose credentials used by an entire team or infrastructure.

Second, the .pth persistence mechanism means the payload ran in every Python process in the affected environment, LiteLLM-specific or otherwise. If a developer had litellm installed in their global Python environment, the malicious .pth file ran every time they opened a Python interpreter.

The systemd backdoor installed by the payload added a third dimension: even if you uninstalled the malicious version, the backdoor would persist on any Linux system that ran the affected versions with sufficient permissions.

Safe Versions

The safe versions are litellm==1.82.6 and below. Versions 1.82.7 and 1.82.8 are the malicious releases flagged in the GitHub advisory. Version 1.82.9, released after the attack was discovered, is clean, but given the circumstances, it’s worth waiting for explicit confirmation from the LiteLLM maintainers before upgrading to any version in the 1.82.x range.

What You Need to Do

Step 1: Check if you installed the affected versions.

pip show litellm

If the version is 1.82.7 or 1.82.8, you installed the malicious release. If you’re not sure whether those versions were ever installed in a given environment, assume they were if the environment ran pip install or pip update on March 24, during the roughly three-hour window when litellm==1.82.7 and 1.82.8 were live.

Step 2: Downgrade to the last clean version immediately.

pip install litellm==1.82.6

Step 3: Check for the malicious .pth persistence file.

On Linux systems, run the following to find any unexpected .pth files:

find /usr/lib/python3* /usr/local/lib/python3* ~/.local/lib/python3* -name "*.pth" -newer /tmp/reference_date

Look for any .pth files that weren’t present before the attack window. If you find unexpected ones, remove them.

Step 4: Check whether the systemd backdoor was installed.

systemctl list-units --type=service | grep -i python

Look for any unexpected Python-related services, then review /etc/systemd/system/ and ~/.config/systemd/user/ for entries you didn’t create.

Step 5: Rotate all credentials that were in range.

This is the most important step and the one most teams will underestimate the scope of. Any credential that existed in an environment that ran litellm==1.82.7 or 1.82.8 should be considered compromised, the full list:

• All LLM API keys (rotate with your providers)
• AWS access keys (rotate in IAM, audit CloudTrail for unexpected usage)
• GCP service account keys (rotate in IAM, audit Cloud Audit Logs)
• Azure service principals (rotate credentials, audit Activity Log)
• Database passwords (rotate and audit query logs)
• SSH keys (revoke old keys, push new public keys)
• CI/CD secrets (rotate in GitHub Secrets, GitLab CI/CD Variables, etc.)
• Kubernetes service account tokens (rotate and audit API server logs)

Step 6: Audit your logs for signs of unauthorized access.

For each cloud provider, check the past 72 hours of access logs. Look for API calls from unexpected IPs or at unexpected times. Check database connection logs and SSH auth logs for anything you don’t recognize.

---

The LiteLLM attack is a reminder that AI infrastructure has become a serious target. The tools used to build and run AI applications, proxy layers, model routers, API gateways, are now part of the attack surface. Treat them accordingly: pin versions, monitor for unexpected updates, and audit credentials regularly. Socket covers PyPI as well as npm, and our Socket.dev supply chain security guide walks through what that monitoring looks like on a Python project.