SURIQ
The wire headlines this week say two malicious LiteLLM packages exposed thousands of organizations. That framing is backwards, and getting it wrong will cause teams to under-scope their response. The LiteLLM releases were downstream casualties. They sat on PyPI for roughly 40 minutes. The breach that actually mattered happened five days earlier, inside the build pipeline of Trivy, the container scanner from Aqua Security that runs in an enormous number of continuous-integration jobs. If your only question after reading the news is "did we install a bad LiteLLM version," you are looking at the wrong door.
New analysis from threat-intelligence firm CloudSEK reconstructs the campaign's reach from roughly 434,000 captured CI/CD files and puts the potential-exposure count north of 2,500 organizations, a list that reportedly includes NVIDIA, Cisco, Deloitte, Volkswagen, FedEx, and Siemens. We covered the FBI's TeamPCP alert in July, when the confirmed tally sat near 1,000. The mapped blast radius has since more than doubled, and the actor now carries a formal designation: Google's threat group labels it UNC6780 and rates it financially motivated.
What actually happened, in order
On March 19, the actor pushed tainted binaries into Trivy releases, beginning at v0.69.4, using leftover access from an earlier intrusion that the vendor had never fully closed out. The flaw is tracked as CVE-2026-33634 at CVSS 9.4, and CISA added it to its Known Exploited Vulnerabilities catalog on March 26. The planted payload was a credential stealer researchers call SANDCLOCK, written to hide its work inside normal-looking telemetry: it wrapped stolen secrets in outbound requests aimed at domains dressed up to resemble monitoring endpoints. SANS Internet Storm Center's tracking put the number of directly exposed pipeline executions above 10,000 across the March 19 to 24 window.
The LiteLLM compromise was a second-order effect of the first. A poisoned Trivy run inside LiteLLM's own pipeline lifted LiteLLM's PyPI publishing token. The actor used that token to push two backdoored releases, 1.82.7 and 1.82.8, on March 24 from 10:39 UTC. According to The Hacker News, PyPI quarantined them after about 40 minutes, and researchers say to treat anything pulled that day before 16:00 UTC as potentially tainted. Those releases went beyond simple credential theft: they also bundled tooling to move laterally through Kubernetes and a backdoor for staying resident, and shipped what they stole to an attacker domain, models.litellm[.]cloud.
So the "malicious LiteLLM" story is real but small. By SecurityWeek's account, the great majority of victims, upward of 95%, had already been hit by the time those LiteLLM releases went up at all. The population that installed a backdoored LiteLLM in a 40-minute window is a subset. The population that ran a poisoned Trivy scan in CI over a five-day window is the story.
What the 2,500 number is, and what it is not
Read the 434,000 files and 2,500 organizations as reconstructed exposure, not a roster of confirmed breaches. CloudSEK assembled the map out of captured CI runner logs, then attributed each artifact to an organization using the fingerprints those logs carry, mainly the runner's host identity and the real committer domains that showed up in them. A company lands on the list because its build logs were scooped up, not because anyone has demonstrated its cloud account was emptied. CloudSEK is explicit that the totals describe potential exposure and that every case still needs to be checked on its own.
That nuance cuts the wrong way for most defenders, though. If your organization is in a dataset of captured CI/CD artifacts, the secrets in those artifacts, your cloud access keys, SSH keys, Kubernetes ServiceAccount tokens, and build-time environment variables, are in the actor's hands and remain valid until you rotate them. "It is only potential exposure" is not a reason to wait. Treat presence in the data as confirmation that rotation is overdue, not as an all-clear.
Who should actually be scoping a response
Here is the practical correction to the headline. The teams most exposed are the ones that ran Trivy as a GitHub Action in CI between March 19 and March 24, whether or not they have ever used LiteLLM. A LiteLLM-framed advisory tells those teams nothing, and some will close the ticket thinking it does not apply. Widen the question:
-
Did a
Trivyaction run in any pipeline in that window? If yes, assume every secret that job could read was captured. Aqua's action is the common denominator, not the AI library. -
Did you pull
LiteLLM1.82.7 or 1.82.8 on March 24? That is the narrow, second exposure. If yes, you also inherit a Kubernetes toolkit and a backdoor, so the cleanup is host-level, not just a version bump. -
Did any downstream image or dependency pin an affected release? The token theft shows how one poisoned build seeds the next. Check what your builds pulled transitively, not just what you named directly.
Patching the scanner does not evict what already leaked
CVE-2026-33634 on the KEV list tells you to update Trivy and pin your actions. Useful, and it closes the delivery route. It does nothing about the credentials captured in March, which stay usable until rotated. This is the recurring lesson of build-pipeline theft: the fix and the recovery are two separate jobs. Even the release delays PyPI and GitHub added only slow a poisoned package; they do nothing for secrets already taken. Update the tooling to stop the next release, then rotate every secret those jobs could reach and move to short-lived credentials so a captured token expires on its own. Detection matters as much as patching here, because the theft looked like telemetry. The signal to hunt for is a CI job reading credential files or environment secrets and then making outbound requests to an unfamiliar host, not a known-bad hash.
The reusable root cause: mutable tags
Strip away the brand names and this is a mutable-reference problem. Trivy's GitHub Action was referenced by a moving tag, so anyone who could push a commit and repoint that tag reached every pipeline that ran the action on its next execution. That is the same weakness behind the 2025 tj-actions/changed-files compromise and the sort of GitHub Actions takeover we have written about before, and it will keep working until teams stop trusting tags for third-party actions. The single control that blunts this class is pinning every third-party action to a full commit SHA, not a tag or a major version. A SHA cannot be silently moved under you. Pair it with a build environment that holds only short-lived, least-privilege credentials, so a captured secret is worth little by the time an actor uses it.
What to do this week
If you run CI, treat this as today's work, not a watch item. Inventory whether Trivy ran in your pipelines during the March 19 to 24 window and, separately, whether any job pulled LiteLLM 1.82.7 or 1.82.8. For anything that matches, rotate cloud keys, SSH keys, Kubernetes tokens, and build-time secrets, and assume they already leaked. Then pin third-party actions to commit SHAs, cut credential lifetimes, and add a detection for build jobs that read secrets and phone out to an unfamiliar domain. The campaign kept expanding after the July alert. Scoping your response to the accurate vector is how you avoid being on the next update to the list.