A major reassessment of the supply chain incident that appeared to compromise over 2,500 organizations through the LiteLLM package has revealed that the vast majority of those victims were actually exposed through an earlier, separate breach of Aqua Security’s Trivy vulnerability scanner. New forensic analysis from SOCRadar has sifted through the incident data and concluded that the LiteLLM attack, while real, was the closing act of a larger campaign that began days earlier with the Trivy compromise. The distinction matters because it shifts where security teams should focus their investigation and remediation efforts, and it exposes how a worm-like malware, attributed to the threat actor TeamPCP and known as Shai-Hulud, used stolen developer credentials to propagate across open source registries in a cascading series of infections.
The Misattribution of the LiteLLM Supply Chain Attack
When news broke that LiteLLM, a widely used AI gateway package, had been compromised, headlines quickly focused on the 2,500 organizations believed to be affected. The initial narrative, fueled by reports from CloudSEK and HudsonRock, painted a picture of a single catastrophic event tied to two poisoned LiteLLM packages published on March 24. The reality, according to SOCRadar’s closer examination of the incident logs, is significantly more complex and points to a compromise that had been unfolding for days before the LiteLLM packages ever appeared on PyPI.
The threat actor, TeamPCP, which has been linked to multiple open source software (OSS) supply chain attacks involving the Shai-Hulud worm, followed a now-familiar pattern. Malicious code was embedded in packages in a way that executed automatically when the infected package was fetched and run, harvesting credentials, tokens, API keys, and other secrets from build environments. The worm then used those stolen developer secrets to modify accessible packages and push malicious versions to the registry, systematically expanding the attack surface. This is exactly how LiteLLM was ultimately compromised, but LiteLLM was not the initial entry point.
Trivy, Not LiteLLM, Was the Initial Vector
Aqua Security’s Trivy vulnerability scanner was the first domino to fall. A malicious build of Trivy was published, and from that point, the infection spread downstream to multiple packages and repositories in a ripple effect. The worm’s behavior, combined with the automated inclusion of malicious libraries in subsequent builds, amplified the reach of the compromise far beyond what a single package attack would typically achieve.
SOCRadar’s analysis of the per-organization records for 2,188 entities reveals a timeline that definitively implicates Trivy as the primary vector. Every record in the dataset carries first-seen and last-seen timestamps. The earliest data collection recorded is March 19 at 18:05 UTC, and the latest is March 24 at 20:09 UTC, a span of just over five days. Critically, for 2,085 organizations, or 95 percent of the 2,188 identified, data collection activity ended before March 24, when the poisoned LiteLLM packages were published to the PyPI registry.
“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 noted in its analysis. The earliest collection occurred 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 closed on March 24 after PyPI quarantined the packages. This pattern, SOCRadar explains, is what persistence on already-infected hosts looks like: the .pth payload kept running after the source of the infection was removed.
How the .pth Payload Bypassed Traditional Protections
The technical mechanism behind the compromise deserves close attention because it circumvented common security practices. The two poisoned LiteLLM package versions published on March 24 were injected with a .pth file, a Python path configuration file that the interpreter executes automatically at startup. This execution happens even if the LiteLLM package itself is never imported by the application, meaning the malicious code ran regardless of whether a developer explicitly called the library. This approach bypasses ignore-scriptscodecodecodecodecode protections, a common safeguard used to prevent arbitrary code execution during package installation, because .pth files are not treated as scripts in the traditional sense. They are executed as part of the Python interpreter’s initialization process, making them an effective and stealthy delivery mechanism.
What Was the Trivy Supply Chain Attack Timeline?
The Trivy supply chain attack unfolded over five days, beginning with the publication of a malicious Trivy build on March 19. Data collection from compromised environments started within 18 minutes of that publication. Activity escalated significantly on March 22 and March 23, when malicious Trivy images were actively hosted on Docker Hub, reaching the largest number of victims. The attack concluded on March 24, when PyPI quarantined the poisoned LiteLLM packages. However, the .pth payload continued to run on already-infected hosts after the source of the infection was removed, demonstrating the persistence capability of the Shai-Hulud worm. The 40-minute window during which the poisoned LiteLLM packages were live represents the final phase of the campaign, not its beginning.
2,188 Organizations Identified, 95 Percent Exposed Before LiteLLM
The dataset analyzed by SOCRadar includes per-organization records for 2,188 entities, with information on credential types, CI/CD platforms, and domains. Of these, 56 percent are rated as high confidence matches, 39 percent as medium confidence, and 6 percent as low confidence. The headline figure of 2,500-plus organizations reflects the broader estimate that includes records lacking attributable identifiers.
The geographic distribution of affected organizations shows Germany, Brazil, and France as the most heavily impacted, though the compromise extended worldwide. The breadth of the attack is a direct consequence of the worm’s ability to use stolen credentials to propagate across registry boundaries and infect dependent packages.
The Six CI/CD Platforms That Became Attack Vectors
The compromise involved six major CI/CD platforms, each of which became a distribution channel for the malware. GitHub Actions, GitLab CI, Jenkins, Bitbucket, CircleCI, and Buildkite all had environments compromised through stolen credentials. For security teams, this list represents the critical surface area that must be audited following any supply chain incident. The worm targeted secrets from build environments broadly, but the data reveals specific categories of credentials that were disproportionately affected.
What Secrets Were Stolen and How Many Organizations Were Affected
Over 1,000 organizations exposed JWT and auth tokens. Hundreds more exposed private keys, AWS access keys, GitLab tokens, OpenAI API keys, Slack webhooks, GitHub Actions tokens, and Google API keys. The highest secret count recorded for a single organization was approximately 3,477, followed closely by another with roughly 3,459. Notably, some organizations with high secret counts had the data concentrated in very few files or repositories. One organization carried 3,459 secrets across just six files, suggesting either a highly centralized secrets management practice that failed catastrophically or a build pipeline that aggregated secrets from multiple sources into a small number of exposed locations.
Committer email addresses were compromised across over 1,100 organizations. In those cases, the attackers obtained both developer identities and machine tokens, creating a dual threat: the ability to impersonate legitimate developers and the means to authenticate as automated systems. This combination is particularly dangerous because it enables both social engineering attacks and direct technical access.
The Brokering of Stolen Credentials on Telegram
The stolen information is already being monetized. SOCRadar reports that a threat actor is offering on Telegram a collection of LiteLLM, Trivy, and CanisterWorm data, likely compiled at various stages of the campaign. The fact that the data is being brokered in a consolidated format underscores the value that attackers place on these credentials and the organized nature of the post-exploitation ecosystem. For organizations that may have assumed the exposure was limited to the brief LiteLLM window, this development signals that their compromised credentials are actively circulating and being used for follow-on attacks.
Implications for Open Source Supply Chain Security
The Trivy-to-LiteLLM attack chain exposes several structural weaknesses in the open source software supply chain. First, the worm’s ability to propagate using stolen credentials demonstrates that a single compromised developer workstation or CI/CD pipeline can lead to a cascade of infections across multiple packages and registries. Second, the use of .pth files to bypass ignore-scriptscodecodecodecodecode protections shows that current security controls are insufficient against sophisticated attack vectors that exploit interpreter-level behavior rather than package-level scripts. Third, the five-day timeline between the initial Trivy compromise and the LiteLLM packages being quarantined highlights the detection gap that exists even for major vulnerabilities in widely used tools.
Security teams should treat any CI/CD environment that used Trivy between March 19 and March 24 as potentially compromised, even if the organization did not directly use LiteLLM. The worm’s ability to persist through .pth files means that simply removing the malicious package is not sufficient; the environment must be thoroughly audited for unauthorized access, credential rotation must be performed, and any secrets that were present in the build environment during that period should be considered compromised. The geographic concentration of victims in Germany, Brazil, and France does not mean organizations elsewhere were immune, as the worm’s propagation followed package dependency graphs rather than geographic boundaries.
Organizations that find themselves in the exposed dataset should prioritize rotating JWT tokens, authentication tokens, and API keys, particularly those associated with the six CI/CD platforms identified in the attack. The presence of OpenAI API keys and Slack webhooks in the stolen data suggests that attackers are targeting AI infrastructure and collaboration tools specifically, likely for their value in further attacks or for direct monetization. The fact that 95 percent of the identified organizations were exposed before the LiteLLM packages were even published means that the 40-minute remediation window widely reported is misleading. The actual exposure period was five days, and the cleanup must reflect that longer timeline.
The TeamPCP group and the Shai-Hulud worm represent a new generation of supply chain threats that combine worm-like propagation with credential harvesting and automated package modification. The attack on Trivy that rippled through to LiteLLM is not an isolated incident but a demonstration of a playbook that can be applied to any popular open source tool with access to CI/CD pipelines and registry publishing capabilities. The industry’s response must evolve from reacting to individual package compromises toward building detection and response capabilities that can trace the propagation path of worm-based attacks across registries, platforms, and organizations. Until then, every developer workstation and CI/CD runner remains a potential entry point for the next wave of automated supply chain compromise.
