LiteLLM Got Backdoored. The Harvest List Is the Story

If you have LiteLLM 1.82.7 or 1.82.8 installed anywhere, stop and rotate your credentials before you read further. Both versions shipped a credential stealer. Yank them, rotate, then come back.

The compromise itself isn’t particularly sophisticated. A threat actor called TeamPCP took over a maintainer’s PyPI account and published two poisoned versions. Same group hit Trivy on March 19, then Checkmarx and KICS. LiteLLM was another target in the same campaign. At this point it’s clearly a campaign targeting security and AI infrastructure tooling specifically, not opportunistic package poisoning.

What’s interesting isn’t the attack vector. It’s what the malware was after.

The .pth trick

The payload was a file called litellm_init.pth in the wheel’s site-packages directory. Python’s site module processes .pth files at interpreter startup. Automatically. No import statement, no user code, no trigger other than a Python process starting after the package is installed.

In a typical developer environment this is bad. In an AI agent environment it’s worse because agents spawn Python processes constantly, sometimes dozens per task. The payload had a lot of opportunities to run.

What it took

Here’s the complete harvest list from the malware:

• ~/.aws/credentials and ~/.aws/config
• ~/.kube/ (kubeconfig files)
• ~/.docker/config.json
• ~/.ssh/ (keys and config)
• GCP service account files
• Azure CLI tokens and service principal configs
• .env files
• Shell history
• LLM API keys from environment variables
• Crypto wallet files

Everything was compressed, encrypted, and exfiltrated to lookalike domains — checkmarx.zone in 1.82.7 and models.litellm.cloud in 1.82.8 — both designed to blend into network logs.

Read that list again. It’s not a generic sweep for anything valuable. It’s a precise map of the credentials that give an AI agent its operational reach. An agent managing cloud infrastructure needs AWS or GCP credentials. An agent deploying code needs SSH keys and a kubeconfig. An agent calling APIs needs those keys. The attacker was targeting the exact things that make agents capable.

I’ve spent time mapping which credential locations AI agents are most likely to touch during normal operation for the work we do on Snare. The list I came up with and this malware’s harvest list are nearly identical. That’s not because we anticipated this specific attack. It’s because anyone reasoning seriously about where value lives in an agentic environment converges on the same answer.

What would have helped

An outbound network policy that blocked unexpected destinations would have stopped the exfiltration even after harvesting. The malware collected the credentials in-process, but with outbound restrictions in place they’d have never reached the attacker’s domains. That’s a meaningful difference between “compromised but contained” and “compromised and exfiltrated.” Rampart, configured with outbound network rules, would have caught this at the egress point.

Canary credentials planted in the harvested locations would have fired alerts when the malware read them, giving immediate signal that something was wrong. Snare plants exactly these kinds of canaries across ~/.aws/, ~/.ssh/, ~/.kube/, and the other targeted paths. Detection, not prevention, but early enough to limit damage from downstream use.

Pinning dependencies and verifying checksums would have prevented the compromised versions from being installed in the first place. That’s the most direct mitigation and the least consistently practiced.

The honest assessment is that most environments had no effective defense here. The package was trusted, the install was routine, and the payload executed before any user code ran. There was no obvious point where someone would have noticed.

The part worth thinking about

TeamPCP’s target selection reflects a real understanding of the developer stack. Trivy is a vulnerability scanner. KICS scans infrastructure-as-code. Checkmarx is a SAST tool. LiteLLM is the routing layer for AI API calls. These are all packages that run in CI/CD with elevated access and broad trust.

Compromising a security scanner is elegant in a cynical way because you’re corrupting the tool people run to check if they’re compromised. LiteLLM is interesting for a different reason: it’s the package that, by design, has access to every LLM API key in the organization. The payload targeted LLM keys specifically alongside the other credentials. That’s not incidental.

What this attack demonstrates is a category of risk that doesn’t fit cleanly into most AI agent security discussions. The agent didn’t misbehave. There was no prompt injection, no policy violation, nothing unusual in the agent’s behavior. A dependency in the environment was compromised. The agent became an exfiltration context without ever doing anything the user didn’t ask for.

The environment the agent runs in is part of the attack surface. That’s an uncomfortable conclusion because it means the blast radius of a supply chain attack scales with how capable your agent is. More access, more reach, more credentials in the environment. More to take.

Supply chain attacks on AI infrastructure are going to keep happening. The question worth sitting with is whether you’d know within the hour if it happened to yours.