LiteLLM PyPI Supply Chain Attack: How It Stole Credentials

On March 24, 2026, two releases of litellm — one of the most popular LLM proxy libraries — went up on PyPI with a credential stealer inside: versions 1.82.7 and 1.82.8. They were live for about three hours before PyPI quarantined the package, and in that window they harvested SSH keys, cloud credentials, Kubernetes secrets and .env files from the machines that installed them.

Correction (October 2026): an earlier version of this post described the attack as a fake, typosquatted package that only listed LiteLLM as a dependency, and said LiteLLM itself was never compromised. That was wrong. The malicious code shipped in the real litellm package, published with a stolen token. The sections below are corrected from the security write-ups linked in them.

I've been tracking supply chain attacks for years, but the LiteLLM supply chain attack stands out because of how precisely it targeted AI developers. If you're building anything with LLMs right now, this is a case study you can't afford to ignore.

What Happened in the LiteLLM PyPI Compromise?

First thing to get straight: LiteLLM itself was compromised. The legitimate litellm package on PyPI — the one maintained by BerriAI — shipped the malware. According to Snyk's analysis, the attacker got LiteLLM's PyPI publishing token through an earlier compromise of Trivy, a security scanner that ran in LiteLLM's CI pipeline: the poisoned scanner action read the PYPI_PUBLISH token from the GitHub Actions runner. With it, the attacker could publish releases that looked exactly like official ones.

Versions 1.82.6 and earlier are clean. The two bad releases used different triggers. In 1.82.7 the payload sat base64-encoded inside litellm/proxy/proxy_server.py, so it ran whenever the LiteLLM proxy was imported or started. In 1.82.8 it moved into a file called litellm_init.pth in site-packages.

That second trick is the nasty one. Python runs .pth files in site-packages through its site module every time the interpreter starts, so 1.82.8 did not even need you to import LiteLLM: any Python process using that environment set it off.

This wasn't a typosquat that careful developers could dodge by checking the package name. It was the real package, under its real name, aimed at the people most likely to have high-value API keys and cloud credentials sitting on their machines: AI developers and the CI systems that build their apps.

How the Multi-Stage Infostealer Worked

The attack followed a pattern I've seen in multiple supply chain compromises: a lightweight first stage that downloads the real payload from an external server. In this case the stealer shipped inside the litellm release itself, and the second stage was a backdoor that kept polling for more.

Stage 1: Collection. Once triggered, the payload swept the machine for anything that unlocks infrastructure. StepSecurity's analysis lists what it went after:

• Environment files — .env, .env.local and .env.production, where most LLM API keys live
• AWS credentials — ~/.aws/ files plus the instance metadata service; with working keys it also pulled values from Secrets Manager and SSM Parameter Store
• Kubernetes credentials — ~/.kube/config and service account tokens
• SSH keys and everything else — ~/.ssh/ keys, Git, Docker, Azure and GCP credentials, shell histories, TLS certificates, CI/CD configs and crypto wallets

Stage 2: Exfiltration and persistence. The haul was encrypted with AES-256-CBC, the session key was wrapped with a hardcoded 4096-bit RSA public key, and the archive was POSTed to models.litellm.cloud, an attacker-controlled domain. The malware also dropped a backdoor, sysmon.py, registered as a systemd user service that asked another attacker domain for new binaries roughly every 50 minutes, by StepSecurity’s measurement. Inside Kubernetes it deployed privileged pods to every node to plant that backdoor on the hosts.

I've worked on production systems where a single leaked API key triggered a five-figure bill in unauthorized compute. How the data leaves matters less than what leaves. The damage comes from what they take, not how they take it.

If you installed 1.82.7 or 1.82.8: treat the machine as compromised. Search your Python paths for litellm_init.pth, check for ~/.config/sysmon/sysmon.py and disable that service, delete node-setup-* pods from kube-system, and rotate every credential the machine or CI runner could reach, including AWS Secrets Manager and SSM values.

Why AI Developers Are Uniquely Vulnerable

Here's the thing about AI supply chain security: the way we build with LLMs creates a perfect storm for credential theft.

The API key problem is real. Unlike traditional web development where your database credentials live in a secrets manager or vault, many AI developers are running LLM API keys as environment variables on their local machines during development. I've reviewed enough codebases to know that .env files with live OpenAI keys sitting in project roots is embarrassingly common. Even among teams that should know better.

Then there's the dependency explosion. A typical AI application in 2026 pulls in dozens of packages — LangChain, LlamaIndex, vector database clients, embedding libraries, orchestration frameworks. When you're pip install-ing five new packages a week to experiment with the latest agent framework, the odds of a typo or a careless copy-paste go way up. Typos aren't the only risk, though. In the LiteLLM incident, developers typed the right name and still got a backdoor, because the attackers published malicious versions of the real package with a stolen publishing token.

And the speed pressure makes it worse. Teams are under intense pressure to ship features, integrate new models, and stay current. I've shipped enough features under deadline pressure to know how easy it is to skip the "let me actually verify this package" step. That careful dependency hygiene just evaporates.

This mirrors the pattern I wrote about in how info-stealer malware targets Chrome saved passwords. Attackers go where the credentials are. Right now, AI developers are sitting on a goldmine of high-value API keys and cloud credentials.

How to Detect and Prevent PyPI Supply Chain Attacks

If you're building AI applications with Python, here are the defenses that actually matter:

Lock your dependencies. Use pip freeze or a proper lock file (poetry.lock, pip-compile) to pin every package to an exact version and hash. This prevents a compromised update from silently replacing a clean package. If you're still running pip install package-name without version pinning in production, stop. Seriously.

Audit new packages before installing. Before you pip install anything new, spend 30 seconds checking: When was it published? How many downloads does it have? Who maintains it? Does the PyPI project page look legitimate? A package with 12 downloads and a one-day-old upload date is a red flag.

Use a dependency scanning tool. Socket.dev, pip-audit, and Safety can detect known malicious packages and flag suspicious behavior in your dependency tree. Integrate these into your CI/CD pipeline so every build gets checked automatically.

Rotate your API keys regularly. Won't prevent the theft, but it limits the blast radius. Rotate your OpenAI, Anthropic, and AWS keys every 30-90 days, and a stolen key becomes worthless faster. Better yet, use short-lived credentials where possible — AWS IAM roles with session tokens, not long-lived access keys.

Get credentials out of environment variables on dev machines. Use a secrets manager. Use a .env file that's in your .gitignore AND gets wiped regularly. Use aws-vault for AWS credentials. The days of export OPENAI_API_KEY=sk-... in your .bashrc need to end.

Run pip install in isolated environments. Virtual environments, containers, or ephemeral CI runners for installing and testing new packages. If a malicious package fires its payload during install, at least it's harvesting credentials from a disposable environment, not your main development machine.

This is all basic hygiene. None of it is exotic. But it becomes critical when you're working in an ecosystem being actively targeted. As I covered in how invisible Unicode attacks can hide in source code, supply chain threats are evolving to exploit the trust developers place in their tools and dependencies.

If you’re shipping RAG features on top of this dependency stack, it’s worth adding automated leak testing to your pipeline, not just package auditing. I put together RAG Data Leakage Test Suite [2026]: CI Red-Team Setup as a practical way to run canary-token and prompt-injection style checks in CI before risky changes land.

One adjacent risk in local-LLM pipelines is tampered model artifacts, especially when GGUF files move through mirrors or ad-hoc downloads. I laid out a team-ready workflow in Verify GGUF Model Hashes Supply Chain [2026]: 10 Steps.

If you want a more systematic way to apply these defenses to agentic stacks, I pulled it together in LLM Supply Chain Security Checklist: Lock Down Agents [2026]. It treats models, MCP servers, tool plugins, and prompt packs as first-class dependencies you can pin, attest, sandbox, and monitor in CI.

The Bigger Picture: AI's Growing Supply Chain Problem

This attack on LiteLLM's ecosystem wasn't an isolated incident. It's part of a broader trend of attackers going after AI and ML developers through package registries. The logic is straightforward: AI developers tend to have access to expensive API keys, cloud infrastructure credentials, and sensitive training data. They're high-value targets.

PyPI has been improving its security posture — mandatory 2FA for critical projects, better malware scanning, faster takedowns. But the fundamental problem remains: PyPI is an open registry. Anyone can upload a package. And the naming system relies on trust that is trivially easy to abuse through typosquatting.

I think this gets significantly worse before it gets better. As AI applications become more complex — think multi-agent systems with dozens of dependencies — the attack surface grows proportionally. Every new framework, every new tool, every new integration point is another opportunity for a malicious package to slip in.

The most dangerous supply chain attacks aren't the ones that break your code. They're the ones that work perfectly while silently forwarding your credentials to an attacker's server.

The LiteLLM incident is a wake-up call, but it shouldn't surprise anyone. A fast-moving ecosystem, an open package registry, high-value credentials, and developers under pressure to ship. That combination was always going to produce exactly this.

Start auditing your requirements.txt today. Get your API keys out of environment variables and into a proper secrets manager. Set up automated scanning in your pipeline. The attackers targeting AI infrastructure are only going to get more sophisticated, and the window where "I didn't know" is a reasonable excuse is closing fast.

Photo by Rahul Viswanath on Unsplash.