On March 24, 2026, two new versions of LiteLLM landed on PyPI: 1.82.7 and 1.82.8. Both were malware.
LiteLLM is the library that tens of thousands of local AI agent builders use every day — it’s a universal proxy that converts API calls for 100+ LLMs into OpenAI format. If you’re running Ollama behind a LiteLLM proxy, or routing multiple providers through it, you’re in the affected group. The packages were uploaded at 08:30 UTC and quarantined by PyPI at 11:25 UTC. Three hours. That’s all it took for 97 million monthly downloads to be at risk.
The TeamPCP threat actor — the same group behind the Trivy and KICS supply chain attacks — used a maintainer account compromised via the prior Trivy incident to publish the poisoned packages.
Version 1.82.7 dropped a double base64-encoded payload to disk (p.py) and executed it whenever litellm --proxy ran or litellm.proxy.proxy_server was imported.
Version 1.82.8 went further. It abused Python’s .pth file mechanism, which runs arbitrary code during interpreter initialization. The malicious litellm_init.pth file triggered on any Python invocation on the system — not just when LiteLLM was explicitly called. Open a Python script for unrelated work? The malware ran.
Once active, the payload systematically harvested:
~/.ssh/)Data was encrypted with AES-256, the key further encrypted with an embedded RSA public key, and exfiltrated to attacker-controlled domains: checkmarx[.]zone (1.82.7) and models[.]litellm[.]cloud (1.82.8).
PyPI pulled the packages fast. But the damage window was real — and the cascade is what makes this interesting for agent builders specifically.
GitGuardian found that 1,705 PyPI packages were configured to automatically pull the compromised LiteLLM versions as transitive dependencies. Packages you’ve never heard of, installed as sub-dependencies of tools you do use, were triggering malware execution silently.
Packages affected:
If any of those are in your agent’s dependency tree, you were exposed even if you never installed LiteLLM directly. That’s supply chain depth most agent developers haven’t modeled.
The LiteLLM attack is the latest example of a pattern that’s been accelerating: adversaries targeting the machine where credentials accumulate, not the network perimeter.
When GitGuardian analyzed 6,943 compromised developer machines from a prior campaign, researchers found 33,185 unique secrets — with at least 3,760 still valid at the time of analysis. More striking: each valid secret appeared in roughly eight different locations on the same machine. The same AWS key in .env, in ~/.aws/credentials, in a shell profile, in an agent’s memory store.
For local AI agent builders, this is the real alert: your dev workstation is dense with credentials because you need them there. Model provider keys. Cloud access tokens. API secrets for tools your agents call. And if you’re running local LLMs with LiteLLM as your proxy layer, you’re adding one more trusted pathway that attackers know to probe.
If you’ve touched LiteLLM in the past 30 days, work through this:
1. Check your installed version.
pip show litellm
If it’s 1.82.7 or 1.82.8, you’re in the blast radius. Update immediately:
pip install --upgrade litellm>=1.82.9
2. Audit your dependency tree.
pip install pipdeptree
pipdeptree | grep -i litellm
Check every package that pulls LiteLLM in as a sub-dependency. If dspy, opik, crawl4ai, or anything else in your stack touched a compromised version, assume exposure.
3. Rotate every credential that touched a machine running those versions. This means: every model API key, cloud credential, SSH key, and secrets store access token that existed on that host. Don’t wait for IOCs. Assume compromise and rotate.
4. Scan your filesystem for secrets that shouldn’t be there. Use ggshield to scan project directories, home folders, and agent memory stores:
ggshield secrets scan path ~/
Pay special attention to directories where local AI agents store their state: agent config folders, log directories, memory files.
5. Check your LiteLLM proxy logs.
If your proxy was running during March 24–25 with a compromised version, the exfiltration may have already occurred. Review outbound connections from your proxy host to checkmarx[.]zone or models[.]litellm[.]cloud — those are the attacker domains.
This attack exploited something deeper than a bad package. It exploited the fact that developer machines accumulate plaintext credentials by design.
Agents need credentials. Local LLMs need API keys. Tool-calling agents need cloud access. Retrieval-augmented agents need vector store connections. And on a dev workstation, all of those end up in .env files, shell profiles, IDE configs, and agent memory stores — often as plaintext because “it’s just local.”
The mitigation isn’t just “don’t install bad packages.” It’s reducing the credential surface area on the machine where you build and test agents:
.env files committed to project treesggshield pre-commit hooks to catch credential leaks before they enter version controlThe LiteLLM supply chain attack is a reminder that your local AI stack isn’t isolated just because it’s running on your laptop. Every package you install, every dependency your tools pull in, every credential sitting in plaintext on disk is attack surface. The TeamPCP campaign — Trivy, KICS, now LiteLLM — shows this isn’t opportunistic. Threat actors are systematically mapping the open-source toolchain and finding the nodes with the most credential density.
If you’re running local AI agents in production or building tools for others who do, treat your dependency tree as a security perimeter. Audit it, pin it, and assume the next supply chain compromise is already in PyPI waiting to be discovered.
Rotate your keys. Check your versions. Then go lock down your agent’s credential hygiene.