Trivy, Not LiteLLM, Was the Real Root Cause Behind the 2,500-Org Compromise
The 2,500-organization compromise reported this week did not start with LiteLLM. It started with Trivy, Aqua Security's open-source scanner, and more than 95% of affected companies were exposed before any malicious LiteLLM package shipped.
The 2,500-organization supply-chain compromise that made headlines this week did not begin where most of us said it did. According to SecurityWeek, the real entry point was Trivy, the open-source vulnerability scanner maintained by Aqua Security, and not the malicious LiteLLM packages that dominated the first round of coverage.
Here is the finding that reframes the whole incident: more than 95% of the affected companies were exposed through the compromised Trivy before a single malicious LiteLLM release was ever published. The LiteLLM packages were a symptom of the Trivy compromise, not its cause. An organization that ran the poisoned Trivy and never installed LiteLLM was still potentially exposed.
We covered the LiteLLM angle in this week's security roundup, alongside a good deal of other reporting that led with LiteLLM as the origin. That framing now looks wrong, and it is worth saying so plainly. When the root cause of a widely reported incident changes, the correction matters more than the original scoop, because the correction is what tells defenders where to actually look.
What Actually Changed
The original story, including SecurityWeek's first report, described a compromise of the LiteLLM project on PyPI that reached more than 2,500 organizations and hundreds of thousands of CI/CD pipelines. The natural read was that developers who pulled a malicious LiteLLM package were the victims, and that the blast radius traced back to that package.
The revised account inverts the sequence. LiteLLM's own build pipeline installed a compromised version of Trivy automatically, and that is how the malicious code reached LiteLLM in the first place. LiteLLM was itself downstream of the Trivy compromise. Because the Trivy problem came first, and because it sat inside a scanner that enormous numbers of teams run in CI, the exposure had already spread widely before the LiteLLM packages ever appeared. The timeline is the whole point: first Trivy, then everything else.
How One Compromised Scanner Reaches Thousands
Trivy is one of the most widely deployed open-source scanners in the cloud-native world. Teams run it inside CI to check container images and dependencies for known vulnerabilities, which places it in a privileged spot with access to build environments, container registries, and the secrets those pipelines carry. A compromise there does not stay contained to one project. It travels with every pipeline that pulls the affected version.
The pre-LiteLLM exposure window is what makes this incident larger than the original telling. A malicious package on PyPI only reaches teams that install that package. A compromised scanner reaches every team that pulls the tainted build, and it does so inside CI, where automation runs without a human deciding to trust anything in the moment. That difference in reach is why more than 95% of the total was already accounted for before LiteLLM entered the story, and it is why the count landed in the thousands rather than the dozens.
The practical consequence is blunt. If your organization ran a compromised Trivy build, you were in scope regardless of whether LiteLLM appeared anywhere in your dependency tree. The malicious LiteLLM packages widened and prolonged the incident, and they gave it a memorable name, but they were not the door the intruder came through. A scanner you trust to find problems runs with enough reach that, once it is tampered with, it becomes an efficient distribution channel in its own right.
Aqua Security's Advisory Is the Source of Truth
Aqua Security, which maintains Trivy, has published a GitHub security advisory about the ecosystem compromise, and independent guidance has since followed from other vendors. If you run Trivy, confirm the specifics against Aqua's own advisory rather than second-hand summaries, including this one. The advisory is where the affected version range and time window are defined, and those two facts decide whether you were in scope.
What Trivy Customers Should Do Now
The defender takeaway shifts with the root cause. If you were waiting to see whether LiteLLM touched your stack, that is the wrong test. The right question is whether a compromised Trivy build ever ran in your environment.
- Audit your Trivy version history. Pull the versions your CI installed, when, and from where, whether release binaries, container images, or GitHub Actions, and compare them against the affected range in Aqua Security's advisory.
- Rotate credentials that touched Trivy pipelines. Treat any secret exposed to a build that ran a compromised Trivy as burned: package-publishing tokens, cloud keys, SSH keys, environment variables, and AI provider keys.
- Verify against the official advisory before standing down. Do not assume you were unaffected because you never installed LiteLLM. Check Aqua Security's advisory and confirm your version and time window first.
The reason to rotate broadly rather than selectively is the range of material these pipelines handle. Reporting on the incident points to a wide haul from affected builds: package-publishing credentials, cloud access keys, SSH keys, API tokens, environment variables, and AI provider keys among them. Any of those that passed through a compromised Trivy run should be treated as exposed, and several of them, publishing tokens especially, are exactly what an intruder needs to push the next malicious package and keep the chain moving. Rotating them closes that loop.
What Is Still Unconfirmed
Several important details are not nailed down, and I am flagging them rather than papering over them. The exact mechanism of the Trivy compromise, whether a poisoned release, a compromised CI pipeline, or stolen maintainer credentials, is not something I can state with certainty from the correction alone. It is also unclear whether every one of the 2,500-plus organizations has been individually notified, and whether the malicious LiteLLM releases were planted in part to draw attention away from the Trivy compromise. Those are open questions, not established facts.
I would also flag the headline number itself. The 95% figure comes from the reporting; the precise split of organizations exposed through Trivy versus LiteLLM may move as more forensic detail comes out. The direction of the correction is clear even if the exact percentage shifts by a few points.
Why the Correction Is Worth Publishing
There is a temptation to quietly update the earlier story and move on. That does readers a disservice. The point of incident reporting is telling defenders where to spend limited hours, and a wrong root cause sends them to the wrong place. If the conversation stays fixed on LiteLLM, teams that never used it will assume they are safe while a compromised Trivy sits in their pipelines. Naming the correction loudly is the responsible move, not an embarrassment to be minimized. It is also a reminder that early attribution in fast-moving supply-chain incidents is provisional, and that the first named component is often the most visible one rather than the first one in the chain.
My Read
The value here is in correcting the record, not in relitigating who reported what first. A lot of coverage, this outlet included, named LiteLLM as the cause when it was closer to a downstream casualty. If you scoped your response around LiteLLM, you may have cleared yourself too early, and that is the practical cost of a wrong root cause. The more durable lesson is about where scanners sit in the supply chain: a tool you trust to find vulnerabilities runs with deep access to your build system, and when that tool is tampered with, it becomes a fast path into thousands of pipelines at once. It is the same structural risk we saw in the recent npm worm outbreak, aimed at a security tool instead of a popular library. Re-check your Trivy exposure, rotate what needs rotating, and treat Aqua Security's advisory as the source of truth.
