LiteLLM Attack: When a Trusted Update Turns Malicious

Last Tuesday we told you about a group of hackers called TeamPCP who poisoned a security scanning tool called Trivy. If you missed it — short version: they replaced the real tool with a fake version that secretly copied passwords and access keys from developer computers while pretending to do its job.

We warned that the stolen credentials would be used to find the next target.

Five days later, they struck again. Bigger this time.

What Is LiteLLM — In Plain English

Imagine your company uses 10 different AI assistants — ChatGPT for some tasks, Google Gemini for others, Claude for others. Each one speaks a slightly different technical language. Normally your developers would have to write 10 separate sets of instructions to talk to each one.

LiteLLM is the universal translator sitting in the middle. Developers write their code once, and LiteLLM handles the conversation with whichever AI is needed. It is the invisible plumbing underneath a huge proportion of AI applications being built today — downloaded 97 million times every month, running quietly inside tools you probably use without knowing it is there.

That invisibility is exactly what made it a valuable target.

How TeamPCP Got Inside — The Master Key Story

Think of PyPI — the website where Python developers download software — like an app store. When LiteLLM's team wants to publish a new version of their library, they use a special password called a publishing token. It works like a master key to their listing on the app store. Whoever holds that key can publish anything under LiteLLM's name, and the app store has no way to tell the difference between the real team and an attacker using the same key.

LiteLLM used Trivy — the tool TeamPCP had already poisoned — as part of their automated build system. Every time LiteLLM released a new version, Trivy ran automatically in the background to check for security issues. Nobody was watching. It was just a machine doing its job.

When the poisoned Trivy ran inside LiteLLM's build system, it found the master key sitting in the environment and quietly copied it. TeamPCP now had the key to LiteLLM's app store listing.

They didn't need to break anything. They walked in through the front door using a key they had stolen from someone else's pocket five days earlier.

This is the real danger of supply chain attacks. You don't attack the target directly. You attack the tools the target trusts — and use those tools to hand you the keys to everything else.

What the Two Poisoned Versions Actually Did

Version 1.82.7 — The Locksmith Who Made a Copy

Picture a locksmith who comes to your office to fix a lock. While working, he quietly makes a copy of your master key, photographs every access card on the desk, and memorises the door codes. Then he fixes the lock perfectly and leaves. You have no idea anything happened.

That is what version 1.82.7 did. Your AI application worked exactly as expected. But in the background, hidden code was scanning your computer for passwords, cloud access keys, SSH keys (the digital keys used to log into servers remotely), API keys (passwords for connecting to external services), and cryptocurrency wallet keys. Everything found was packaged up and sent silently to TeamPCP's server.

Version 1.82.8 — The Listening Device in the Electricity Meter

This version went much further. It planted a hidden file called litellm_init.pth on the machine.

Python — the programming language LiteLLM is built on — has a special folder it checks automatically every time any Python command runs. Files in this folder execute silently before anything else. Not just when LiteLLM is used. Any Python command. On anything.

Think of it like someone hiding a tiny listening device inside your office building's electricity meter. Every time anyone turns on a light — any floor, any room, anything electrical — the device activates. A developer running a completely unrelated Python script on a machine that had LiteLLM 1.82.8 installed would trigger the malware without ever opening LiteLLM, without ever using AI, without any warning at all.

Ironically, version 1.82.8 also had a bug that caused Python to crash in a loop. That crash is what drew attention and helped researchers find the attack. The attackers' own mistake limited the damage.

The Chain — This Was Not Random

March 19 — Trivy poisoned. Credentials stolen from thousands of developers.
March 23 — KICS (a security tool) hit using credentials from Trivy victims.
March 24 — LiteLLM hit using credentials stolen from LiteLLM's own build system via Trivy.

Each attack is funded by the one before it. Think of it like a thief who steals a restaurant's supplier contact list, calls every supplier pretending to be the restaurant, and uses those relationships to reach even more victims.

TeamPCP posted on Telegram: "The snowball effect from this will be massive." Security researchers confirm this campaign is not finished.

→ 75 Versions of Trivy Were Poisoned — Check Your Pipeline Now

Indicators of Compromise (IOCs)

# LiteLLM Supply Chain Attack — What To Check

# Step 1 — Check your installed version
pip show litellm
# Version 1.82.7 or 1.82.8 = treat machine as compromised

# Step 2 — Hunt for the hidden persistence file
find / -name "litellm_init.pth" 2>/dev/null
# If found — delete it immediately, then check for sysmon.service

# Step 3 — Check for hidden background service
systemctl --user list-units | grep sysmon
# If found — disable and delete it

# Step 4 — Clear your package cache
pip cache purge

# Step 5 — Pin to safe version
pip install litellm==1.82.6

# Kubernetes users — check for unauthorized deployments
kubectl get pods -n kube-system | grep node-setup

# Block at firewall
models.litellm[.]cloud  (fake domain — not official LiteLLM)
checkmarx[.]zone        (TeamPCP command server)

SOC Alert Priorities

Priority 1 — Run pip show litellm on every machine immediately. Laptops, servers, build machines, staging environments. Version 1.82.7 or 1.82.8 means compromised. Rotate every credential on that machine before doing anything else.

Priority 2 — Hunt for litellm_init.pth on every machine. Uninstalling the bad version does not remove this file. It survives upgrades and keeps running silently until you manually find and delete it.

Priority 3 — If your team ran Trivy between March 19–21, you have a separate problem. Your own build credentials may have been stolen — meaning your own software could be TeamPCP's next target. Check independently.

Priority 4 — Block the C2 domains at your firewall. Any machine that communicated with models.litellm[.]cloud or checkmarx[.]zone already sent data out. Investigate those machines immediately.

Priority 5 — Pin all dependencies to specific versions. pip install litellm without a version number will always fetch the latest — which attackers can poison at any time. pip install litellm==1.82.6 locks you to a verified safe version.

The ZyberWalls Perspective

Three attacks in six days. Each one using the previous attack to unlock the next door.

The developer who discovered this attack didn't find it with a security scan. They found it because a plugin they were testing quietly pulled LiteLLM in as a hidden ingredient — they didn't even know it was on their machine. That is how modern software works. Your application depends on hundreds of libraries. Those libraries depend on hundreds more. Most organisations don't know everything they have installed.

TeamPCP knows this. That is why they target the invisible infrastructure — the tools everyone uses but nobody watches.

Pin your dependencies. Watch your build systems. And when any tool in your supply chain is compromised, rotate your credentials immediately — not after you confirm your own machine was hit. By then, the window has already closed.