Trivy, Not LiteLLM, Drove the March Supply Chain Breach
SOCRadar's forensics show 95% of the 2,188 affected orgs were compromised via the Trivy scanner before any LiteLLM package was poisoned.
Dave "Kilobaud" FerrisThe attribution on the March 2026 supply chain incident has been revised, and the revision matters for any security team still working through their exposure.
New analysis from SOCRadar, reported by SecurityWeek, shows that approximately 95 percent of the 2,188 organizations identified in the dataset were compromised before the malicious LiteLLM packages appeared on PyPI. Those packages were published March 24. The actual campaign started March 19, when the first malicious Trivy build was published. Data collection began eighteen minutes later.
By March 22 and 23, the compromised Trivy container images were active on Docker Hub and the attack was already running at scale.
What Trivy did versus what LiteLLM did
Trivy, Aqua Security’s open-source container vulnerability scanner, was the initial infection vector. The malware embedded in the tampered builds behaved like a worm: it harvested credentials from the host environment, then used the stolen developer secrets to modify and poison downstream packages — a chain that eventually reached LiteLLM.
LiteLLM’s role was downstream and derivative. Attackers injected a .pth file into the poisoned releases that executed at Python interpreter startup, neatly sidestepping install-script protections. But the credential collection had already been running for five days by the time those releases were pulled.
SOCRadar characterizes LiteLLM as “the closing act, not the whole play.”
What the dataset shows
From SOCRadar’s analysis of the credential haul:
- Over 1,000 organizations had JWT tokens and authentication tokens exposed
- More than 1,100 had committer email addresses taken
- A single organization lost approximately 3,477 secrets — cloud keys, SSH keys, API tokens — in one campaign pass
- Confidence breakdown across the 2,188-organization dataset: 56 percent high, 39 percent medium, 6 percent low
The problem with security tooling as attack surface
The LiteLLM story was always going to be the one that got named. A PyPI package poisoned for 40 minutes has a version number, a pull timestamp, and a tidy remediation step: check your lockfile, rotate credentials if you installed it. That is the kind of thing a security advisory can communicate cleanly.
Trivy is a different category of problem. Vulnerability scanners live inside CI/CD pipelines with elevated permissions by design — they access the environments they audit. When the tool doing the checking is the compromised one, the blast radius is everything it touched during normal operation, not just the narrow window where a bad package was available on PyPI.
That gap — five days of Trivy-based collection versus forty minutes of LiteLLM availability — is where the actual scale of this incident lives. The package pulled from a registry in under an hour is easy to find in retrospect. The scanner that processed every build for five days straight is harder to isolate, and the log trail is usually in whatever your CI/CD system happens to retain.
What to check if you haven’t already
If Trivy ran in your pipelines between March 19 and March 24, 2026, treat that window as potentially compromised and work the same credential category list SOCRadar flagged: cloud provider keys first, SSH private keys second, Kubernetes service account tokens third, database passwords fourth. Pull your build logs to scope which systems Trivy touched. Audit authorized_keys files and RBAC bindings for any service accounts that were active.
The LiteLLM check — which pip install logs from March 24 — is still worth doing. It just shouldn’t be the only check.
Source: SecurityWeek — Trivy, Not LiteLLM Behind the 2,500 Org Compromise
Found this useful? Share it.
