The 2,500-org compromise was a Trivy problem. LiteLLM was the closing act.

SOCRadar reports that most of the organizations counted as victims of the LiteLLM supply chain attack were already compromised before the poisoned LiteLLM packages existed, with the exposure originating in Aqua Security's Trivy scanner and spreading downstream through packages and repositories ^[1][3]. That reframes the scoping question for every team that responded to this: if your rotation list was derived from a LiteLLM dependency search, it was built on the wrong root cause.

The headline number came from CloudSEK and HudsonRock, which said earlier this week that more than 2,500 organizations were likely affected by the LiteLLM attack ^[2]. SOCRadar says it worked from a record-level set covering 2,188 entities, each with first-seen and last-seen timestamps, credential types, CI/CD platforms, and domains ^[7]. The earliest timestamp is March 19 at 18:05 UTC and the latest March 24 at 20:09 UTC, a span of just over five days ^[8]. For 2,085 of those organizations, or 95 percent, collection activity ended before March 24, the day the two poisoned LiteLLM versions were published and stayed live for roughly 40 minutes ^[9][5]. That leaves about 103 organizations, some 5 percent of the identified set, whose activity ran into the LiteLLM window at all ^[10].

The timeline sits on the upstream event instead. According to SOCRadar, the first collection happened 18 minutes after the malicious Trivy build was published on March 19, surged on March 22 and 23 while malicious Trivy images were live on Docker Hub, and tailed off on March 24 after PyPI quarantined the packages ^[11][12]. "The 40 minutes everyone reported was the closing act, not the whole play," the firm says ^[13]. It also notes that the payload kept running on already-infected hosts after the source of infection was removed ^[14].

The mechanics explain why narrow scoping fails. The malicious code ran automatically when an infected package was fetched and executed, harvesting credentials, tokens, API keys and other secrets, then used stolen developer secrets to modify other reachable packages and publish poisoned versions, which is how LiteLLM itself was hit ^[15]. In LiteLLM's case the injection was a .pth file that Python executes at interpreter startup even if LiteLLM was never imported, which sidesteps ignore-scripts protections ^[6]. Six CI/CD platforms appear in the data: GitHub Actions, GitLab CI, Jenkins, Bitbucket, CircleCI and Buildkite ^[16]. Germany, Brazil and France were the most affected countries ^[17].

What is in attacker hands is broad. More than 1,000 organizations exposed JWT and auth tokens, with hundreds exposing private keys, AWS access keys, GitLab tokens, OpenAI API keys, Slack webhooks, GitHub Actions tokens and Google API keys ^[18]. The largest single row holds roughly 3,477 secrets, the next roughly 3,459, and one 3,459-secret row came from just six files ^[19]. Committer email addresses were taken from more than 1,100 organizations, giving the attackers developer identities alongside machine tokens ^[20]. SOCRadar is explicit that these are exposure figures from a reconstructed sample rather than confirmed compromises or a complete census, with 56 percent of records rated high confidence, 39 percent medium and 6 percent low ^[22][21].

Watch the brokering. One actor is already selling a bundle of LiteLLM, Trivy and CanisterWorm data on Telegram, apparently compiled at different stages of the campaign ^[24]. Anything harvested between March 19 and March 24 should be treated as live until rotated, and the search should start at Trivy in build images and cached toolchains, not at a LiteLLM version pin.