# The Security Scanner Was the Weapon: How Trivy, Not LiteLLM, Burned 2,500 Organizations
Everyone fixated on the wrong package.
When CloudSEK and HudsonRock reported this week that over 2,500 organizations were compromised in the LiteLLM supply chain attack, the implicit assumption was obvious: someone installed poisoned LiteLLM packages and paid for it. That's the story that spread. It's also mostly wrong.
SOCRadar dug into the per-organization records — timestamps, credential types, CI/CD platforms, domains — and found something that reframes the entire incident. For 2,085 of the 2,188 organizations they examined, data collection ended *before* March 24, when the malicious LiteLLM packages even appeared on PyPI. The poisoned LiteLLM builds were live for roughly 40 minutes before PyPI quarantined them. Forty minutes. That's not an attack window. That's an epilogue.
The actual story begins five days earlier with Trivy.
## The Scanner Got Scanned
Trivy is Aqua Security's open source vulnerability scanner — the kind of tool that sits at the center of a CI/CD pipeline precisely because you trust it. You run Trivy to find dangerous software. The irony of what TeamPCP did here is surgical.
On March 19, malicious builds of Trivy appeared. The earliest credential collection recorded in SOCRadar's dataset happened 18 minutes after that. By March 22 and 23, when poisoned Trivy container images were sitting on Docker Hub being pulled into automated pipelines across the world, the campaign was in full surge. Organizations weren't installing sketchy AI packages they didn't vet. They were running their security scanner.
This is how the Shai-Hulud worm — the malware infrastructure behind TeamPCP — operates. The infection doesn't wait for human error in the traditional sense. It executes the moment an infected package is fetched and run, harvesting credentials, tokens, and API keys. Then it uses those stolen secrets to push malicious versions of *other* packages the compromised developer can reach. Each victim becomes a vector. The ripple effect into LiteLLM was downstream consequence, not the original sin.
## What .pth Files Do That You Probably Don't Think About
The technical persistence mechanism deserves specific attention, because it's not well understood outside Python security circles.
The attackers injected a .pth file into the poisoned packages. Python processes .pth files automatically during interpreter startup — not at import time, not when you call the library. At startup. If the file is on your sys.path, it executes. That means organizations running the malicious packages didn't even need to import litellm to get burned. The payload fired anyway. It also means the common advice to run packages with --ignore-scripts does nothing here, because .pth files aren't scripts in the npm sense. They're a Python interpreter feature.
The SOCRadar finding that captures this clearly: credential collection continued after PyPI quarantined the packages. The source of infection was gone. The infected hosts weren't. That's what persistence looks like when it's wired into interpreter startup rather than a running process.
## A Credential Fire Sale
The scale of what was taken is worth sitting with. Across the confirmed victims:
One unnamed organization had 3,459 secrets sitting across just six files. That's not a sprawling enterprise with thousands of repos; that's concentration. SOCRadar describes brokered secrets as a next concern, and they're right to. Credential theft at this scale doesn't get used all at once. It gets sorted, valued, and sold.
The CI/CD platforms in scope — GitHub Actions, GitLab CI, Jenkins, Bitbucket, CircleCI, and Buildkite — represent the full stack of how software gets built professionally. There's no niche victim profile here.
## HackWire Analysis
The attribution correction here is significant beyond this single incident. The security industry has a chronic problem with headline attribution in supply chain attacks: the package that gets pulled, quarantined, and named tends to absorb the blame even when it's a downstream casualty. LiteLLM's 40-minute exposure window was visible and containable, so it became the story. Trivy's multi-day exposure — rooted in Docker Hub images that were live for far longer — was the actual damage vector, and it received a fraction of the coverage.
That asymmetry has consequences. Organizations doing incident response right now may be checking whether they installed LiteLLM in late March, finding they didn't, and concluding they're clean. If they ran Trivy between March 19 and March 24, they may not be.
This also represents a maturation of the Shai-Hulud worm's operational playbook. Targeting a security scanner specifically — a tool that runs with elevated access, that's trusted by CI/CD pipelines, that's rarely itself scanned — is a deliberate choice. It's not clever by accident. Security tooling is categorically under-scrutinized in supply chain threat models because the entire premise of the tool is that it finds problems rather than introduces them. TeamPCP found that assumption and pulled on it.
For defenders: the immediate question isn't "did we install LiteLLM?" It's "what Trivy version were we running the week of March 19, and what did our pipeline do with it?" Check your Docker Hub pull logs, your CI/CD execution history, and audit for .pth files in your Python environments. Rotate any secrets your CI/CD systems could have touched during that window — all of them, not just the ones you think were exposed.
The secrets are already brokered. The question now is whether someone has already used yours.
— HackWire Editorial
---
## Related Coverage