LiteLLM 95% Pre-Publication Exposure Correction: Trivy Was the Primary Vector — One Unrevoked Token, 20 Days, 76 of 77 trivy-action Tags Poisoned — Most of 2,488 Affected Organizations Never Installed LiteLLM at All
Sources: SecurityWeek — “Over 2,500 Organizations Impacted by LiteLLM Supply Chain Attack” (SOCRadar correction: most organizations affected via Trivy incident, not LiteLLM packages — primary correction source) · CloudSEK — “2,500+ Companies and 434,000 CI/CD Pipelines Exposed” (primary research, full chain analysis including unrevoked token and 20-day window detail) · The Hacker News — “Malicious LiteLLM Releases Tied to Trivy Hack May Have Exposed 2,100+ Organizations” (CVE-2026-33634 CISA KEV confirmation, trivy-action tag detail) · The CyberSec Guru — Full attack chain forensics (76 of 77 trivy-action version tags, setup-trivy replacement) · Help Net Security — “153GB of stolen credentials surface after LiteLLM supply chain attack” (Hudson Rock 153GB archive detail) · BreachHistory — Full forensic reconstruction (Snyk, Trend Micro, Cycode public forensics cited) · OODAloop — CloudSEK quote: “one unrevoked token, three tools deep” | CVE: CVE-2026-33634 — CISA KEV (added March 26, 2026) — BerriAI LiteLLM 1.82.7–1.82.8 + Trivy components | Root cause: Leaked automation token, rotated but not fully revoked — left ~20-day window for force-push over Trivy’s published version tags | Trivy components affected: v0.69.4 release · 76 of 77 trivy-action version tags · setup-trivy tags | Trivy compromise date: March 19, 2026 | LiteLLM packages date: March 24, 2026 | LiteLLM PyPI window: ~40 minutes | Trivy exposure window: ~20 days | Scope: 2,488 corporate domains · 118,829 CI runner dumps · 433,909 files · 153GB | SOCRadar finding: Most of 2,500 affected organizations were hit via Trivy, not LiteLLM packages | TeamPCP targeting intent: LiteLLM was never directly targeted — it was collateral damage from Trivy compromise flowing automatically into LiteLLM’s build pipeline | FBI FLASH: FLASH-20260702-01 — covers full chain, affiliated actors actively weaponizing
“Trivy, then the build system, then the LiteLLM release: one un-revoked token, three tools deep. That chain is what turns a single credential leak into ecosystem-wide exposure.” — CloudSEK. Most of the 2,488 affected organizations were hit at step one. The 40-minute PyPI window was the last move, not the first. If you cleared yourself on LiteLLM 1.82.7/1.82.8 and never checked Trivy, your investigation is not complete.
On August 16, 2026, SOCRadar published a material correction to the LiteLLM supply chain breach narrative: most of the 2,488 organizations identified as victims in the 153GB credential archive were exposed earlier than previously reported — via the Trivy incident beginning March 19, not via the LiteLLM PyPI window on March 24. According to CloudSEK, TeamPCP, the threat actor behind multiple high-profile open source software (OSS) compromises, never targeted LiteLLM directly. The open source Python library and proxy server was compromised after its CI pipeline installed the compromised Trivy version automatically.
This correction changes two things that directly affect enterprise security teams. First, the affected population is larger: Trivy is one of the most widely used open-source vulnerability scanners in the world — far more organizations use Trivy in CI/CD than use LiteLLM. Second, the audit window starts earlier: organizations that investigated the LiteLLM breach and concluded they were safe because they never installed versions 1.82.7 or 1.82.8 conducted an incomplete investigation. The correct starting point is March 19 — five days before the LiteLLM packages appeared on PyPI — when TeamPCP’s poisoned Trivy began flowing into pipelines across the ecosystem.
The corrected attack chain — three tools, one token, 20 days
DataWater’s Article #59 described the attack chain accurately in its architecture, but the full forensic picture now available from CloudSEK, The CyberSec Guru, and BreachHistory adds precision that changes the operational implications for affected organizations:
| Stage | Date | What Happened | Who Was Exposed | Duration |
|---|---|---|---|---|
| Stage 0 — Root cause | Before March 19 | TeamPCP obtained a Trivy automation token. The token had been rotated but not fully revoked — leaving an active credential that still had write access to Trivy’s GitHub repository and publication infrastructure. | No organizations yet — attacker has access but hasn’t acted | Unknown pre-incident period |
| Stage 1 — Trivy compromise | March 19, 2026 | TeamPCP used the unrevoked token to publish malicious Trivy v0.69.4 and force-push malicious code over 76 of 77 trivy-action version tags and replace affected setup-trivy tags. Any CI/CD pipeline using these tags received poisoned scanner code that harvested all secrets accessible to the runner environment. | Every organization using Trivy via affected version tags in CI/CD — the primary victim population | ~20 days |
| Stage 2 — LiteLLM build poisoned | March 19–24, 2026 | LiteLLM’s build pipeline used Trivy unpinned from the system package manager (apt). When the compromised Trivy ran inside LiteLLM’s CI environment, the attacker’s code accessed secrets available to that environment — including LiteLLM’s PyPI publishing tokens. | LiteLLM’s own CI infrastructure — this is how TeamPCP obtained the ability to publish to PyPI as LiteLLM | Days between Trivy compromise and package publication |
| Stage 3 — LiteLLM PyPI packages | March 24, 2026 | TeamPCP used the stolen PyPI tokens to publish malicious LiteLLM versions 1.82.7 and 1.82.8 to the Python Package Index. These packages contained a .pth Python startup hook harvesting all secrets from any environment that installed them. | Organizations that installed LiteLLM 1.82.7 or 1.82.8 during the ~40-minute window — a subset of total victims | ~40 minutes |
CloudSEK’s Threat Intelligence team obtained the exposure data through its intelligence sources, including records relating to organizations, CI/CD pipelines, and credential/token exposures associated with the March 2026 supply-chain cascade involving compromised Trivy, Checkmarx KICS, and related components. The key operational finding in the corrected narrative: “Trivy, then the build system, then the LiteLLM release: one un-revoked token, three tools deep. That chain is what turns a single credential leak into ecosystem-wide exposure.”
The specific Trivy components affected — what to check in your pipeline
On March 19, attackers used compromised credentials to publish a malicious Trivy v0.69.4 release, force-push malicious changes to 76 of 77 affected trivy-action version tags, and replace the affected setup-trivy tags. These are the three specific Trivy components that security teams need to audit in their pipeline histories:
- Trivy v0.69.4 package: If any pipeline installed Trivy v0.69.4 from any source around March 19–24, that installation contained malicious code. Check pip install trivy, apt install trivy, and container image pulls that included Trivy at this version.
- trivy-action version tags (76 of 77 affected): The trivy-action GitHub Action is how most CI/CD pipelines integrate Trivy into GitHub Actions workflows. If your pipeline used trivy-action without pinning to a specific commit SHA — using a version tag like @v0.x.x instead — you received the poisoned version during the ~20-day compromise window. Audit your GitHub Actions workflow files for any trivy-action references that were tag-based rather than commit-pinned.
- setup-trivy tags: A second GitHub Action for Trivy installation was also replaced. Same audit applies — tag-based references during the window received malicious code.
The critical detail about the 20-day window: unlike the LiteLLM 40-minute PyPI exposure, the Trivy compromise was active for approximately 20 days. The initial entry point was the Trivy security scanner used inside LiteLLM’s build pipeline, which stayed compromised for roughly 20 days. During those 20 days, every automated CI/CD run that pulled Trivy via affected version tags — including routine daily builds, nightly security scans, and PR validation workflows — harvested and exfiltrated the runner’s secrets. Organizations running daily CI with Trivy may have had credentials stolen on multiple separate occasions during the window, across multiple pipelines and environments.
CVE-2026-33634 — in CISA KEV, added March 26
The ecosystem compromise is tracked as CVE-2026-33634, added to CISA’s Known Exploited Vulnerabilities catalog on March 26. The Hacker News confirmed on August 12 that the CVE record now lists BerriAI LiteLLM 1.82.7 through 1.82.8 as affected alongside the Trivy components. The CVE’s inclusion of Trivy components alongside the LiteLLM packages is the formal confirmation that this is a single chained incident, not two separate events. The CISA KEV entry was added two days after the LiteLLM packages appeared on PyPI — meaning CISA was tracking this from the start. For federal agencies and organizations operating under BOD 26-04, remediation requirements under the KEV entry apply to both the Trivy components and the LiteLLM packages.
Why the correction matters — the three categories of wrongly-cleared organizations
SOCRadar’s finding that most victims were exposed via Trivy rather than LiteLLM packages creates three specific categories of organizations that may have incorrectly concluded they are not affected:
- “We don’t use LiteLLM” — incorrect clearance. The majority of affected organizations never installed LiteLLM at all. They used Trivy in their CI/CD pipelines and were compromised directly. If your organization used Trivy via affected version tags around March 19–24, you are in the primary victim population regardless of LiteLLM usage.
- “We checked, we didn’t install 1.82.7 or 1.82.8” — incomplete investigation. This conclusion only addresses Stage 3 of the attack chain. It says nothing about whether your Trivy usage in the weeks preceding March 24 exposed your CI runner environment through Stage 1. An organization that uses Trivy daily in GitHub Actions and never installed LiteLLM may have had credentials harvested on every daily build run for 20 days.
- “We use LiteLLM but not those versions” — may also be incomplete. If your organization uses LiteLLM and also uses Trivy, both exposure vectors need to be audited independently. Clearing one does not clear the other.
The complete remediation checklist — updated for Trivy as primary vector
- Audit pipeline history for Trivy usage March 19–April 8, 2026. Search GitHub Actions logs, CI system logs, and container build logs for any invocation of trivy-action, setup-trivy, or Trivy v0.69.4 during the ~20-day window. This is the primary exposure check, regardless of LiteLLM usage.
- For any pipeline that ran Trivy via affected tags during the window: rotate all credentials readable by that runner. AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY · GCP service account credentials · Azure client secrets and tenant tokens · GitHub and GitLab personal access tokens · Kubernetes service account tokens · SSH private keys accessible to the runner · All AI provider API keys (OpenAI, Anthropic, Google, Mistral, etc.) · Database connection strings · Slack signing secrets · Salesforce client secrets · Any .env file contents accessible to the runner environment.
- Separately audit for LiteLLM 1.82.7/1.82.8 installation. Check pip freeze outputs, container layer histories, and package lock files for any record of these versions. This is a secondary check — not the primary exposure vector for most organizations.
- Check CVE-2026-33634 remediation status under BOD 26-04. Federal agencies: verify both the Trivy components and LiteLLM packages are addressed in your KEV remediation tracking.
- Pin all third-party GitHub Actions to commit SHAs, not version tags. The Trivy compromise was possible because tag-based references could be replaced with malicious code — a commit SHA reference would have been immutable and unaffected. Audit every GitHub Actions workflow file for tag-based Action references and convert to commit SHA pinning. This is the single most effective prevention for this attack class in the future.
- Implement token rotation with full revocation verification. The root cause of this entire incident is a token that was rotated but not fully revoked. Audit your token lifecycle processes: when a token is rotated, confirm the old token is invalidated — not just that a new token was issued. Check GitHub, PyPI, npm, and all other publishing platforms where your organization has automation tokens.
- Review cloud audit logs back to March 19. AWS CloudTrail, GCP Audit Logs, Azure Monitor — look for anomalous API calls, unusual IAM activity, or unexpected data access patterns that may reflect credential use by TeamPCP-affiliated actors during or after the exposure window.
Related DataWater Coverage — The Full Supply Chain Arc
- → LiteLLM Supply Chain Breach — Article #59 — Original DataWater Brief: The 40-Minute Window, 153GB, AWS/Cisco/Samsung. This Article Corrects and Expands That Coverage.
- → Cordyceps CVE-2026-32345 — Article #33 — CI/CD Hijack from Free GitHub Account: The Same trivy-action Tag Replacement Vector TeamPCP Used at Scale
- → Anthropic Disclosure — Article #52 — Mythos 5 Published Malicious PyPI Package to 15 Systems: The Same PyPI Supply Chain Vector, Different Actor, Controlled Context
- → SharePoint CVE-2026-55040 — Article #58 — The Credentials Trivy Exposed Include the Domain Credentials That Enable SharePoint JWT Impersonation
- → JADEPUFFER — Article #41 — First AI Agent Ransomware Ran on Stolen AI API Keys: The Same Credential Type Exposed by Both Trivy and LiteLLM Stages of This Breach
- → Langflow CVE-2026-9198 — Article #54 — AI API Credential Exposure: Langflow Exposed One Organization’s AI Keys via RCE. Trivy Exposed 2,488 Organizations’ AI Keys via Supply Chain.
- → Browse the full DataWater threat archive →
Sources and further reading
- SecurityWeek — “Over 2,500 Organizations Impacted by LiteLLM Supply Chain Attack” (SOCRadar Correction: Most Victims via Trivy, Not LiteLLM Packages)
- CloudSEK — “2,500+ Companies and 434,000 CI/CD Pipelines Exposed” (Full Chain: Unrevoked Token, 20-Day Window, Three Tools Deep)
- The Hacker News — “Malicious LiteLLM Releases Tied to Trivy Hack” (CVE-2026-33634 CISA KEV, 76-of-77 trivy-action Tags)
- The CyberSec Guru — Full Attack Chain Forensics (Trivy v0.69.4, trivy-action Tag Replacement, setup-trivy Detail)
- Help Net Security — “153GB of stolen credentials surface after LiteLLM supply chain attack” (Hudson Rock 153GB Archive)
- BreachHistory — Full Forensic Reconstruction (Snyk, Trend Micro, Cycode Public Forensics)
- Cryptonomist — “AI Supply Chain Breach Exposes 2,500+ Companies in 2026” (20-Day Window, Unrevoked Token Detail)
DataWater publishes daily cybersecurity intelligence for enterprise and government security leaders. Article #61 — August 16, 2026. Correction to: Article #59 — LiteLLM Supply Chain Breach (August 13). Previous: Taiwan AI Agent Swarm (August 15) · SharePoint CVE-2026-55040 (August 12). Full archive →
