Why 2,500-Org Breach Wasn't What It Seemed

The supply chain attack that was initially blamed on the LiteLLM package may have had a different source all along. According to a new analysis from cybersecurity firm SOCRadar, most of the 2,500 organizations thought to have been affected by the LiteLLM compromise were actually exposed in an earlier, separate incident involving Aqua Security's Trivy scanner. The finding recasts the timeline of a campaign that has been attributed to the threat actor TeamPCP.

A Chain Reaction, Not a Single Event

What started as a compromise of Trivy rippled through the open source ecosystem, according to SOCRadar's report. The malware's worm-like behavior, combined with the automated inclusion of malicious libraries in downstream builds, meant that a single infection could spread far beyond its original target. The result was a cascade that hit multiple packages and repositories, not just one.

Earlier in the week, CloudSEK and HudsonRock had estimated that more than 2,500 organizations were affected by the LiteLLM attack. SOCRadar's analysis suggests that most of those victims were, in fact, caught up in the Trivy compromise rather than the LiteLLM package itself.

The TeamPCP Pattern

All of the compromises linked to TeamPCP followed a similar playbook, SOCRadar notes. Malicious code was automatically executed when an infected package was fetched, harvesting credentials, tokens, API keys, and other secrets from the affected systems. The worm then used those stolen developer secrets to modify other accessible packages and push malicious versions to the registry, expanding the attack's reach.

That is how LiteLLM was compromised. Two poisoned versions of the package were published on March 24 and remained online for roughly 40 minutes. They contained a .pth file that Python would execute automatically at interpreter startup, even if LiteLLM was never imported, bypassing the protections that would normally prevent such scripts from running.

Timing Tells the Real Story

By examining the incident data more closely, SOCRadar found per-organization records for 2,188 entities, including timestamps, credential types, CI/CD platforms, and domains. The records showed that data collection activity began on March 19 and ended on March 24, a span of just over five days.

For 2,085 of those organizations — or 95% of the identified total — data collection had already stopped before March 24, the day the poisoned LiteLLM packages were published. "That timing lines up with the upstream Trivy compromise rather than the LiteLLM install window. The 40 minutes everyone reported was the closing act, not the whole play," SOCRadar said.

The earliest collection activity began just 18 minutes after the malicious Trivy build was published on March 19. Activity surged on March 22 and March 23, when malicious Trivy images were live on Docker Hub, and then closed on March 24 after PyPI quarantined the packages.

The .pth Payload Kept Running

The timing pattern also indicates that the infection was persistent, even after the source was removed. "[This] is what persistence on already-infected hosts looks like: the .pth payload kept running after the source of the infection was gone," SOCRadar noted. This means that even if the initial vector was Trivy, the malicious code continued to operate on infected systems well after the immediate trigger had been blocked.

The campaign affected six CI/CD platforms: GitHub Actions, GitLab CI, Jenkins, Bitbucket, CircleCI, and Buildkite. The impact was global, with Germany, Brazil, and France hit hardest.

Brokered Secrets

The malware was indiscriminate in what it collected, but some patterns stood out. SOCRadar found that over 1,000 organizations had JWT and auth tokens exposed, and hundreds more had private keys, AWS access keys, GitLab tokens, OpenAI API keys, Slack webhooks, GitHub Actions tokens, and Google API keys compromised.

The data also shows that some organizations were disproportionately affected. "The highest secret count in the set is roughly 3,477 [the organization has not been named], followed by roughly 3,459. Several high-secret rows rest on very few files or repositories. One row carries 3,459 secrets across just six files," SOCRadar noted. This suggests that a small number of organizations may have aggregated a large amount of sensitive data in a concentrated set of files.

In addition, committer email addresses were compromised across over 1,100 organizations. This means attackers gained both developer identities and machine tokens, potentially allowing them to impersonate legitimate developers or access systems through automated processes.

Confidence and Exposure

SOCRadar also provided a breakdown of confidence levels for the affected organizations. "Of the 2,188 organizations in the record-level set, 56% are rated high confidence, 39% medium, and 6% low, with figures rounded. Headline reporting cites 2,500+ organizations; the difference reflects which records carry attributable identifiers," the firm said.

"High-confidence matches are keyed on CI host identity and legitimate committer domains, meaning whose systems a captured file came from, rather than any observed use of a stolen credential. These are exposure figures rather than confirmed compromises, drawn from a reconstructed sample rather than a complete census," SOCRadar added. This distinction is crucial: the numbers are a measure of exposure, not proof of active compromise.

Why It Matters

The new analysis could change how security teams respond to this incident. If most of the affected organizations were compromised through Trivy, then chasing the LiteLLM package alone would be incomplete. Resolving the issue would require checking for the .pth payload and other indicators across the entire build environment, not just in one package.

It also suggests that the worm's persistence might mean compromised systems remain at risk even after the original vector is removed. For organizations that were affected, the report underscores the value of treating the entire supply chain as potentially untrusted, and of verifying the integrity of every link in the build pipeline.