Trivy Supply Chain Compromise: TeamPCP IOCs, Affected Versions, and CI/CD Hunt Guide

Why This Matters

The Trivy incident is strategically important because it shows attackers targeting security tooling and CI/CD workflow plumbing, not just application dependencies. A compromised scanner or setup action can inherit visibility into repositories, build logs, tokens, and deployment material by design.

Affected Package Coordinates

Trivy
trivy@0.69.4
trivy@0.69.5
trivy@0.69.6

GitHub Actions references to review
uses: aquasecurity/trivy-action@<compromised-release-window>
uses: aquasecurity/setup-trivy@<compromised-release-window>

Verified Claims

Claim 1: Multiple Trivy versions and related workflow integrations were exposed as part of the compromise window

Verified.

• Microsoft publishes the affected Trivy versions and associated hunting guidance.
• The structured slug data extends that to GitHub Actions references that defenders should inventory alongside direct binary installs.

Why this matters: Teams that only review workstation package versions may miss workflow-based exposure.

Claim 2: The activity used recognizable exfiltration and staging indicators, including typosquatted or campaign-linked domains

Verified.

• Microsoft lists scan.aquasecurtiy.org, 45.148.10.212, 94.154.172.43, tdtqy-oyaaa-aaaae-af2dq-cai.raw.icp0.io, and other indicators.
• The dataset also preserves tpcp.tar.gz, /tmp/runner_collected_, and libredtail-http as useful pivot points.

Why this matters: The hunting surface is wider than version inventory. Network and temporary collection artifacts can reveal systems that no longer retain the vulnerable version.

Claim 3: The Trivy incident is part of the larger TeamPCP campaign rather than a standalone scanner-only event

Verified with high confidence.

• Microsoft documents the core compromise mechanics and indicators.
• Kodem places Trivy inside a longer campaign timeline spanning additional developer and CI/CD tooling.

Why this matters: Defenders should pivot from Trivy exposure into adjacent campaign indicators instead of scoping only one tool.

Attack Chain

1. Attackers abused a trusted Trivy distribution or workflow path.
2. Affected versions or GitHub Actions references executed in CI/CD or developer environments.
3. Temporary collection and archive behavior aligned with indicators such as /tmp/runner_collected_ and tpcp.tar.gz.
4. Network communication touched campaign-linked infrastructure.
5. The attacker leveraged access to harvest secrets or stage exfiltration from build-oriented systems.

Technical Mechanics

Execution Surface

This incident matters because Trivy often runs where build credentials and source visibility already exist. The attacker does not need privilege escalation if the compromised tool already operates inside a privileged workflow.

Indicators

scan.aquasecurtiy.org
45.148.10.212
94.154.172.43
tdtqy-oyaaa-aaaae-af2dq-cai.raw.icp0.io
models.litellm.cloud
plug-tab-protective-relay.trycloudflare.com
audit.checkmarx.cx
tpcp.tar.gz
/tmp/runner_collected_
libredtail-http

Workflow Exposure Model

The most important triage distinction is between:

• direct Trivy installs on endpoints or runners
• GitHub Actions workflows that fetched or invoked Trivy-related actions during the compromise window

Both paths can place attacker-controlled logic into environments that have access to secrets and repository contents.

Detection Opportunities

rg -n "trivy@0.69.4|trivy@0.69.5|trivy@0.69.6|aquasecurity/trivy-action|aquasecurity/setup-trivy" .github/workflows package-lock.json
rg -n "scan.aquasecurtiy.org|45.148.10.212|94.154.172.43|tdtqy-oyaaa-aaaae-af2dq-cai.raw.icp0.io|models.litellm.cloud|plug-tab-protective-relay.trycloudflare.com|audit.checkmarx.cx|tpcp.tar.gz|/tmp/runner_collected_|libredtail-http" /var/log "$WORKSPACE"

Analyst focus:

• GitHub Actions history during the compromised release window
• runner filesystem traces matching /tmp/runner_collected_
• outbound traffic to campaign infrastructure
• repositories or secrets accessible to workflows that ran Trivy

Open Questions And Confidence Notes

• Microsoft is strongest on concrete indicators and defender hunting guidance.
• Kodem is strongest on campaign context and linkage to later TeamPCP compromises.
• Exact code-level behavior inside every affected distribution path is less explicit than the network and artifact evidence, so some lower-level execution detail remains campaign-level rather than package-diff-level.

Sources

• Microsoft Security Blog
• Kodem TeamPCP timeline