Last updated: March 2026
Key Takeaways
- On March 24, 2026, a threat group called TeamPCP published poisoned versions of LiteLLM (a Python package with 97 million monthly downloads) to PyPI, stealing SSH keys, cloud credentials, crypto wallets, and API keys from every machine that installed it. The attack was only discovered because a bug in the malware crashed a developer's computer.
- The attack was enabled by a cascading chain of compromised developer tools: an AI bot breached Trivy (a security scanner), which gave attackers access to LiteLLM's publishing credentials. The package that manages your LLM API keys became the weapon used to steal them.
- If you run any local AI tools that use Python packages, this incident is a direct warning: every dependency you install is a link in a chain of trust, and any link can be poisoned. We walk through exactly how to audit and protect your setup below.
What Happened
LiteLLM is a popular open-source Python library that acts as a universal interface for large language model APIs. If you use multiple AI providers (OpenAI, Anthropic, local models via Ollama), LiteLLM lets you route requests through a single gateway. It is downloaded roughly 3.4 million times per day and sits in the dependency tree of major AI agent frameworks, MCP servers, and LLM orchestration tools like DSPy and CrewAI.
On March 24, 2026, versions 1.82.7 and 1.82.8 of LiteLLM were published to the Python Package Index (PyPI) containing a three-stage credential-stealing payload. These versions were not published by the legitimate maintainers. A threat group calling itself TeamPCP had stolen the maintainer's PyPI publishing token and used it to push malicious code directly to the package registry.
Version 1.82.8 was particularly dangerous. It included a .pth file, a type of Python startup hook that executes automatically every time any Python process starts on the machine. You did not need to import LiteLLM or even run code that used it. Simply having the package installed was enough to trigger the payload. Every Python script, every IDE language server, every pip command on the affected machine was silently running the attacker's code.
What the Malware Stole
The payload harvested everything it could find on the infected machine: SSH private keys and configs, AWS, Google Cloud, and Azure credentials, Kubernetes secrets, database passwords, Git credentials, environment variables containing API keys, cryptocurrency wallet files, SSL private keys, shell history, and recent authentication logs. The stolen data was encrypted with RSA-4096 and exfiltrated to an attacker-controlled domain designed to look like a legitimate LiteLLM service (models.litellm.cloud).
On machines running Kubernetes, the malware went further. It deployed privileged pods to every node in the cluster and installed a persistent backdoor (sysmon.service) that polled a command-and-control server for additional payloads.
How It Was Discovered
The discovery was accidental. A developer at FutureSearch was using the Cursor IDE with an MCP (Model Context Protocol) plugin. That MCP plugin pulled in LiteLLM as a transitive dependency, a package the developer never explicitly installed and may not have known existed in their dependency tree. When the poisoned version installed, the .pth file's process-spawning mechanism contained a bug: it created an exponential fork bomb that consumed all available RAM and crashed the machine.
The crash was the only reason anyone noticed. If the attacker had written more careful code, the credential theft would have continued silently. As Andrej Karpathy (former OpenAI research lead and Tesla AI director) noted in a widely shared post, the attacker essentially "vibe coded" the malware, and its sloppiness is the only thing that saved potentially thousands of organizations from undetected infrastructure compromise.
The Full Attack Chain: How One Breach Became Many
The LiteLLM compromise did not happen in isolation. It was the third wave in a coordinated campaign that exploited one breach to enable the next, exactly the kind of cascading failure that makes supply chain attacks so dangerous.
Stage 1: Trivy (February-March 19)
In late February 2026, an autonomous AI agent called hackerbot-claw exploited a misconfigured GitHub Actions workflow in Aqua Security's Trivy, one of the most widely used open-source vulnerability scanners in the cloud-native ecosystem. The bot stole a privileged access token from the CI environment. Aqua Security discovered the breach and attempted to rotate credentials, but the rotation was incomplete. The attackers retained access.
On March 19, TeamPCP used the surviving credentials to force-push malicious commits to 75 of 76 version tags in Trivy's GitHub Action repository. Any CI/CD pipeline that ran Trivy that day had its secrets harvested and sent to attacker infrastructure. Because the legitimate Trivy scan still ran normally afterward, many users saw clean output and had no reason to suspect compromise.
Stage 2: Checkmarx KICS (March 23)
Using credentials stolen from the Trivy breach, TeamPCP compromised Checkmarx's KICS (Keep Infrastructure as Code Secure) GitHub Action the following day. All 35 release tags were hijacked within four hours. The same credential-stealing payload was deployed through a different trusted tool, expanding the pool of stolen secrets further.
Stage 3: LiteLLM (March 24)
LiteLLM's CI/CD pipeline used Trivy as part of its automated build process, installing it without pinning to a specific version. When the compromised Trivy ran inside LiteLLM's pipeline, it exfiltrated the PyPI publishing token. With that single credential, the attackers published the poisoned LiteLLM packages to PyPI, reaching every developer and automated system that pulled the latest version.
The pattern is clear: breach a security tool, use the stolen credentials to breach the next tool in the chain, repeat. Each compromised tool sits inside thousands of CI/CD pipelines, each pipeline holds credentials to other services, and each stolen credential opens the door to the next compromise. Gal Nagli, head of threat exposure at Wiz (a Google-owned cloud security firm), described it as the open-source supply chain "collapsing in on itself."
Why This Matters for Your Home AI Setup
You might be thinking: "I don't run LiteLLM, so this doesn't affect me." That assumption is dangerous for two reasons.
First, LiteLLM is a transitive dependency for many AI tools. If you have ever run pip install dspy, pip install crewai, or installed various MCP plugins, you may have pulled LiteLLM into your environment without knowing it. The developer who discovered this attack found it precisely this way: an MCP plugin in their IDE silently installed LiteLLM as a sub-dependency.
Second, the attack pattern is not specific to LiteLLM. Any Python package, any npm module, any dependency in any language can be compromised the same way. TeamPCP has openly stated they intend to continue targeting open-source projects and security tools. The technique of compromising CI/CD credentials to push malicious package versions is now a proven, repeatable playbook.
If you followed our guide on building a zero-cost AI agent stack with Ollama, n8n, and AnythingLLM, or if you are running any Python-based AI tools on your home network, your dependency tree is a chain of trust. This incident demonstrates what happens when a single link in that chain breaks.
The MCP Connection: A New Attack Surface
The Model Context Protocol (MCP) deserves special attention here. As we covered in our MCP explainer for network engineers, MCP is the emerging standard for connecting AI assistants to external tools and data sources. It is powerful precisely because it allows dynamic, real-time integration between AI models and the services they interact with.
That power comes with a cost. MCP plugins can pull in dependencies automatically, often without explicit user awareness. In this incident, a developer using Cursor IDE had an MCP plugin that silently added LiteLLM to their environment. The developer never ran pip install litellm. They never chose to trust that package. An automated tool-integration protocol made that decision for them.
This does not mean MCP itself is flawed. The protocol is a communication standard, not a package manager. But the ecosystem of MCP plugins and servers is young, and the dependency trees behind those plugins are not always transparent. If you are building local AI infrastructure that uses MCP connections, you need to understand what packages those connections pull in and how to lock them down.
How to Protect Your Local AI Stack
Whether you run Ollama on a mini PC, a full n8n automation server, or just experiment with Python-based AI tools, these steps reduce your exposure to supply chain attacks.
1. Check If You Were Directly Affected
Run pip show litellm in every Python environment on your machine, including virtual environments and Docker containers. If you see version 1.82.7 or 1.82.8, treat that environment as fully compromised. Remove the package, purge your pip cache (pip cache purge), and rotate every credential that was accessible from that machine: SSH keys, cloud tokens, database passwords, API keys, Git credentials, and anything stored in .env files.
Also check for persistence mechanisms. Look for ~/.config/sysmon/sysmon.py and ~/.config/systemd/user/sysmon.service on Linux systems. If you run Kubernetes, audit the kube-system namespace for pods matching node-setup-*.
2. Pin Your Dependencies
Never install Python packages without version pinning in any environment that touches credentials or sensitive data. Use a requirements.txt or pyproject.toml with exact version numbers, not ranges. For example, use litellm==1.82.6 (the last known clean version), not litellm>=1.64.0.
Generate and commit lock files (pip freeze > requirements.txt or use tools like pip-tools or uv) so you have a verifiable record of exactly which versions are installed.
3. Implement a Dependency Cooldown
Security researchers have found that waiting 7 to 14 days before accepting new package versions prevents the majority of supply chain attacks. Automated scanners from firms like Socket, Aikido, and Snyk continuously monitor package registries and typically flag malicious packages within days. A one-week cooldown gives those systems time to catch problems before the packages reach your machine.
For home lab setups, this is simple: do not run pip install --upgrade on the day a new version drops. Wait a week. Check release notes. Verify the version exists on the project's official GitHub repository before installing it.
4. Isolate Your AI Environment
If you followed our network security for local AI guide, you are already running your AI tools on an isolated network segment. This incident reinforces why that matters. A credential stealer on your AI mini PC should not have access to your main workstation's SSH keys, your NAS credentials, or your home network's admin interfaces.
At minimum, run AI tools in dedicated virtual environments or Docker containers with no access to your host system's credential stores. Do not share .ssh, .aws, or .env directories into containers unless absolutely necessary. On your network, keep AI workloads on a separate VLAN from your primary devices, as described in our security hardening guide.
5. Audit What Your MCP Plugins Actually Install
If you use MCP-enabled tools like Cursor, Claude Desktop, or other AI coding assistants with plugin ecosystems, take time to understand the dependency trees behind those plugins. Before enabling a new MCP server or plugin, check its package.json or requirements.txt to see what it pulls in. Run the installation in an isolated environment first and inspect what gets added to site-packages.
This is the least convenient step on this list, but it is the one most directly validated by this incident. The developer who discovered the LiteLLM attack did not choose to install LiteLLM. An MCP plugin chose for them.
6. Prefer Local-First, Minimal-Dependency Tools
One of the core arguments for self-hosted AI infrastructure is reducing your dependency on external services and the trust chains they require. Ollama, for example, is a single binary with no Python dependency tree at all. If your workflow allows it, running models directly through Ollama's API instead of routing through a multi-provider gateway like LiteLLM eliminates an entire category of supply chain risk.
This is not always practical. Multi-provider routing, advanced prompt management, and tool orchestration often require additional packages. But every dependency you add is a trust decision. Make those decisions consciously, not automatically.
The Bigger Picture: AI Tools Attacking AI Infrastructure
One detail in this story deserves attention beyond the immediate operational response. The initial breach in this chain, the Trivy compromise in late February, was carried out by an autonomous AI agent called hackerbot-claw. This was a bot that systematically scanned GitHub repositories for exploitable workflow configurations, found one in Trivy, and used it to steal privileged credentials.
An AI tool attacked a security tool. The stolen credentials were used to compromise an AI development tool. That compromise was discovered through an AI coding assistant's plugin system. We are now in a world where AI agents are active participants on both sides of the security equation, finding vulnerabilities, exploiting them, and (accidentally) detecting the exploitation.
This is not a hypothetical scenario from a policy paper. It happened this week. It is the strongest possible argument for understanding and controlling the infrastructure your AI tools run on. If you do not know what is in your dependency tree, if you do not control your network segmentation, if you do not own the trust decisions in your stack, you are delegating those decisions to an ecosystem that just demonstrated it cannot protect itself.
As we have covered across our AI infrastructure guides, the path to reducing this risk is not to avoid AI tools entirely. It is to run them on infrastructure you understand and control: local models on hardware you own, on networks you have segmented, with dependencies you have audited. That is what digital sovereignty means in practice, and this week made the case more clearly than any theoretical argument could.
Frequently Asked Questions
Was my machine compromised if I have LiteLLM installed?
Only if you installed or upgraded to version 1.82.7 or 1.82.8 on March 24, 2026. Run pip show litellm to check your installed version. If you are on an earlier version (1.82.6 or below) and did not upgrade that day, you were not affected by this specific attack. The compromised versions were available on PyPI for approximately three hours before being removed.
I use Ollama for local AI. Am I affected?
Ollama itself is not affected. It is a standalone Go binary that does not depend on Python packages. However, if you also use Python-based tools alongside Ollama (for example, n8n workflows that call Python scripts, or AnythingLLM with custom integrations), check those Python environments separately. The risk is in the Python dependency tree, not in Ollama's runtime.
What is a transitive dependency, and why does it matter here?
A transitive dependency is a package that you never explicitly installed but that was pulled in automatically because something you did install depends on it. For example, if you install Package A and Package A requires Package B, Package B is a transitive dependency. In this incident, many developers were exposed to LiteLLM not because they chose to install it, but because another tool (an MCP plugin, DSPy, CrewAI, or similar) listed it as a requirement. This is why auditing your full dependency tree matters: the packages you did not choose can be just as dangerous as the ones you did.
What is a .pth file, and why is it dangerous?
A .pth file is a Python startup hook. When placed in the site-packages directory, Python's site module automatically processes it every time the interpreter starts. Unlike a normal Python module that only runs when imported, a .pth file runs on every Python process: scripts, pip commands, IDE language servers, everything. In this attack, the .pth file meant the malware executed even if you never used LiteLLM in your code. CPython maintainers have acknowledged this as a security risk, but no patch has been applied to the mechanism itself.
How can I prevent supply chain attacks on my home lab?
No single measure eliminates the risk, but layering these practices significantly reduces your exposure: pin all dependencies to exact versions instead of version ranges; wait 7 to 14 days before adopting new package releases; run AI tools in isolated Docker containers or virtual environments without access to host credentials; segment your network so compromised workloads cannot reach other devices; audit the dependency trees of any MCP plugins or AI tools before installing them; and keep sensitive credentials (SSH keys, API tokens, cloud access keys) off machines that run experimental or frequently updated software.
Is MCP (Model Context Protocol) itself a security risk?
MCP as a protocol standard is not inherently insecure. It defines how AI models communicate with external tools and data sources. The risk comes from the MCP plugin ecosystem: plugins can install arbitrary dependencies, make network requests, and execute code on your machine. In this incident, an MCP plugin in Cursor IDE pulled LiteLLM as a transitive dependency without the developer's explicit knowledge. The protocol is sound; the supply chain behind the plugins requires the same scrutiny you would apply to any software you install on a sensitive system. See our MCP explainer for a deeper look at how the protocol works and how to evaluate MCP servers before connecting them.
Who is TeamPCP, and should I expect more attacks like this?
TeamPCP is the threat group responsible for this campaign. They compromised Trivy (March 19), Checkmarx KICS (March 23), and LiteLLM (March 24) in rapid succession, using credentials stolen from each breach to enable the next. They have publicly stated their intention to continue targeting open-source projects and security tools. The underlying technique, compromising CI/CD credentials to push malicious packages through legitimate publishing channels, is well-documented and increasingly common. This is not the last supply chain attack of this kind. It is the most visible one this month.
