Trivy Supply Chain Attack: What Happened and How to Protect Your CI/CD Pipeline

The Attack That Shook DevSecOps

On March 19, 2026, the security community woke up to a nightmare scenario: Trivy, one of the most widely-used open-source vulnerability scanners, had been compromised. The tool that thousands of organizations trust to find vulnerabilities had become the vulnerability itself.

A threat actor group known as TeamPCP exploited residual credentials from an earlier breach to hijack 75 of 77 version tags in the official aquasecurity/trivy-action GitHub Action, replacing them with credential-stealing malware. Every CI/CD pipeline running Trivy scans was potentially compromised.

This is the full breakdown of what happened, the technical details of the attack, and the concrete steps you need to take right now.

Timeline of the Breach

The attack unfolded in stages:

Late February 2026: Attackers exploited a misconfiguration in Trivy's GitHub Actions environment, extracting a privileged access token. This gave them a foothold into repository automation and release processes.

March 1, 2026: Aqua Security disclosed the initial incident and executed credential rotation. However, the rotation was incomplete — the threat actor retained residual access via still-valid credentials.

March 19, 2026: Using the retained credentials, TeamPCP launched the full attack:

• Published a malicious trivy v0.69.4 release
• Force-pushed 76 of 77 version tags in aquasecurity/trivy-action to credential-stealing malware
• Replaced all 7 tags in aquasecurity/setup-trivy with malicious commits
• The malware, self-described as "TeamPCP Cloud Stealer," dumped Runner.Worker process memory, harvested SSH, cloud, and Kubernetes secrets, encrypted the data using AES-256 + RSA-4096, and exfiltrated it to a remote server

March 20-22, 2026: Follow-on attacks emerged. The CanisterWorm, a self-propagating malware, spread across 47 npm packages. Infostealers were distributed via Docker images, and a Kubernetes wiper was deployed against compromised clusters.

Technical Deep Dive: How the Attack Worked

Stage 1: Token Extraction

The initial compromise targeted GitHub Actions environment variables. When a workflow runs, GitHub injects tokens that allow the action to interact with the repository. TeamPCP found that Trivy's workflow configuration exposed a token with write access to releases and tags.

# Vulnerable workflow pattern (simplified)
jobs:
  release:
    permissions:
      contents: write  # This is the dangerous permission
    steps:
      - uses: actions/checkout@v4
      - run: goreleaser release
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

Stage 2: Tag Hijacking

With release permissions, the attackers force-pushed new commits to existing tags. This is particularly insidious because most organizations pin their GitHub Actions to tags (like @v1 or @v2) rather than specific commit SHAs:

# How most teams reference Trivy (vulnerable)
- uses: aquasecurity/[email protected]

# How teams SHOULD reference actions (pinned to SHA)
- uses: aquasecurity/trivy-action@7b7aa264d83dc58691451798927ecb1ada5d8720

Stage 3: Credential Harvesting

The malicious action replaced the scanning logic with a sophisticated stealer:

1. Process Memory Dump: Read the Runner.Worker process memory to extract environment variables, including secrets
2. File System Scan: Searched for SSH keys, kubeconfig files, cloud provider credentials, and Docker configs
3. Encryption: All harvested data was encrypted using AES-256 with RSA-4096 key wrapping
4. Exfiltration: Data was sent to attacker-controlled infrastructure, with a fallback mechanism that created a repository named tpcp-docs in the victim's GitHub organization

Impact Assessment

The blast radius of this attack is enormous:

• Trivy-action has over 15,000 stars and is used in hundreds of thousands of CI/CD pipelines
• Any pipeline that ran between March 19-20 using tag-based references potentially leaked secrets
• Compromised secrets include: GitHub tokens, AWS/GCP/Azure credentials, Kubernetes configs, SSH keys, Docker registry credentials
• The follow-on CanisterWorm affected 47 npm packages, creating secondary supply chain compromises

How We Responded (Self-Hosted Advantage)

When this news broke, we audited our infrastructure within hours. Because we self-host our entire CI/CD pipeline on Gitea with Gitea Actions, our exposure was limited:

1. Gitea Actions isolation: Our runners operate in isolated Docker containers with no internet egress except to our private registry
2. SHA pinning: We had already adopted SHA-pinned action references after the tj-actions/changed-files incident in 2025
3. Network segmentation: CI/CD runners cannot reach external endpoints — all artifact pulls go through our internal proxy
4. Secret rotation: We rotated all CI/CD secrets within 2 hours as a precautionary measure

Concrete Steps to Protect Your Pipeline

Immediate Actions (Do Today)

1. Audit Your Workflows

Search for any reference to Trivy actions in your repositories:

# Find all workflows using trivy-action
grep -r "aquasecurity/trivy" .github/workflows/
grep -r "aquasecurity/setup-trivy" .github/workflows/

2. Check for Compromise Indicators

Look for the tpcp-docs repository in your GitHub organization — its presence indicates successful exfiltration.

Review workflow run logs from March 19-20 for unusual network activity or process spawning.

3. Rotate All Secrets

If your pipelines ran Trivy between March 19-20:

• Rotate all GitHub tokens (PATs, deploy keys, app tokens)
• Rotate cloud provider credentials (AWS access keys, GCP service accounts)
• Regenerate SSH keys used in CI/CD
• Update Docker registry credentials
• Rotate Kubernetes service account tokens

Long-Term Hardening

4. Pin Actions to Commit SHAs

Never reference GitHub Actions by tag. Always use the full commit SHA:

# Before (vulnerable to tag hijacking)
- uses: aquasecurity/[email protected]

# After (immutable reference)
- uses: aquasecurity/trivy-action@7b7aa264d83dc58691451798927ecb1ada5d8720

5. Use Dependabot for Action Updates

Configure Dependabot to track GitHub Action versions and alert you to updates:

# .github/dependabot.yml
version: 2
updates:
  - package-ecosystem: github-actions
    directory: /
    schedule:
      interval: weekly

6. Implement Least-Privilege Permissions

Every workflow should declare the minimum required permissions:

permissions:
  contents: read
  security-events: write  # Only if needed for SARIF upload

7. Network-Isolate Your Runners

Self-hosted runners should operate behind a firewall with explicit allowlists for required endpoints. Block all outbound traffic except:

• Your artifact registry
• Your source control server
• Required package registries (with hash verification)

8. Implement Action Allowlists

GitHub Enterprise and Gitea both support restricting which actions can run in your organization. Create an explicit allowlist of approved actions.

9. Use SLSA and SBOM Verification

Verify the provenance of every tool in your pipeline. SLSA (Supply-chain Levels for Software Artifacts) provides a framework for ensuring build integrity.

The Bigger Picture

The Trivy attack is not an isolated incident. It follows a pattern of supply chain attacks targeting developer tools:

• 2024: xz-utils backdoor targeting SSH
• 2025: tj-actions/changed-files compromise
• 2026: Trivy ecosystem compromise (this incident)

Each attack is more sophisticated than the last. The security tools we rely on are themselves becoming attack vectors. This creates a fundamental trust problem: who watches the watchers?

The answer is defense in depth. No single tool or practice will protect you. You need:

• Immutable references (SHA pinning)
• Network isolation
• Least-privilege access
• Runtime monitoring
• Regular secret rotation
• Supply chain verification (SLSA, SBOM, Sigstore)

Conclusion

The Trivy supply chain attack is a watershed moment for DevSecOps. It demonstrates that even the most trusted security tools can become weapons. The organizations that weathered this storm best were those with self-hosted infrastructure, SHA-pinned dependencies, and defense-in-depth security models.

If you are still running CI/CD pipelines with tag-pinned actions and unrestricted network access, the Trivy attack should be your wake-up call. The next supply chain compromise is not a matter of if, but when.

Start with SHA pinning today. Implement network isolation this week. Build a comprehensive supply chain security strategy this quarter. Your pipeline depends on it.