Trivy GitHub Actions Supply Chain Compromise: How TeamPCP Turned a Security Scanner Into a Credential Stealer

Executive Summary

The irony is hard to miss. Trivy, the vulnerability scanner running inside thousands of CI/CD pipelines, just became the attack vector of a supply chain compromise where most scanners and ASPM could fail.

On March 19, 2026, threat actor TeamPCP compromised Aqua Security’s Trivy vulnerability scanner for the second time in three weeks, (disclosed by Paul McCarty) injecting a multi-stage credential stealer into official GitHub Actions used by over 10,000 CI/CD workflows globally.

The attacker force-pushed 75 of 76 version tags in aquasecurity/trivy-action to malicious commits containing a three-stage infostealer that dumped Runner.Worker process memory, harvested SSH keys, cloud credentials, and Kubernetes tokens. A backdoored Trivy v0.69.4 binary was also published to GitHub Releases, Docker Hub, GHCR, and Amazon ECR.

The root cause was incomplete credential rotation after the February 28 hackerbot-claw breach, which left the attacker with residual access. The compromise has cascaded into the npm ecosystem via CanisterWorm, a self-propagating worm affecting more than 47 packages.

Key Takeaways

• 75 of 76 version tags in aquasecurity/trivy-action were force-pushed to malicious commits containing a three-stage infostealer
• Backdoored Trivy v0.69.4 binary published to GitHub Releases, Docker Hub, GHCR, and Amazon ECR
• Root cause: incomplete credential rotation after the February 28 hackerbot-claw breach
• Compromise cascaded into npm via CanisterWorm, a self-propagating worm affecting more than 47 packages
• Safe versions: trivy v0.69.3, trivy-action @0.35.0 (SHA: 57a97c7e), setup-trivy v0.2.6

TL;DR for Engineering Teams

What it is: Supply chain compromise of Trivy scanner and GitHub Actions (trivy-action, setup-trivy), injecting a multi-stage credential stealer attributed to TeamPCP. No CVE assigned.

Where it bites: Any CI/CD pipeline referencing aquasecurity/trivy-action by version tag (all tags except 0.35.0), setup-trivy (7 tags), or Trivy binary v0.69.4.

Why it matters: Payload runs before the legitimate scan — pipelines appear normal. Stealer dumps Runner.Worker memory, harvests SSH keys, cloud creds, K8s tokens, crypto wallets. 10,000+ workflows affected.

Patch status: Malicious artifacts removed. Tags restored with v-prefix. Immutable releases enabled. Safe versions: trivy v0.69.3, trivy-action v0.35.0, setup-trivy v0.2.6.

Immediate action: Pin to SHA 57a97c7e7821a5776cebc9bb87c984fa69cba8f1. Rotate all pipeline secrets if any workflow ran a compromised tag between March 19 17:43 UTC and March 20 ~05:40 UTC. Block 45.148.10.212 and scan.aquasecurtiy[.]org.

Vulnerability Overview

Technical Anatomy

Root Cause: Incomplete Credential Rotation After First Breach

The attack chain begins with the February 28, 2026 incident. An AI-powered bot called hackerbot-claw exploited a misconfigured pull_request_target workflow (apidiff.yaml) in the Trivy repository. This workflow had been present since October 2025 and was flagged by Boost Security’s poutine tool on November 29, 2025 — over three months before exploitation.

Aqua Security rotated credentials after the first incident. The credential rotation was not atomic. The attacker retained access to credentials missed during rotation, enabling the March 19 attack.

Exploit Path

1. Entry point — Compromised credentials and imposter commits. TeamPCP made imposter commits spoofing maintainer DmitriyLewen. At 17:43:37 UTC on March 19, the v0.69.4 tag was pushed. The attacker compromised the aqua-bot service account and used it to push malicious workflows to tfsec, traceeshark, and trivy-action. Additional credentials (GPG keys, Docker Hub, Twitter, Slack tokens) exfiltrated to Cloudflare Tunnel C2.

2. Trigger — Force-pushed 75 version tags with spoofed metadata. Each forged commit started from master HEAD, swapped entrypoint.sh with the infostealer, and cloned the original commit’s metadata including timestamps and commit message. GitHub’s release page showed no visible change. The “Immutable” badge still displayed on each poisoned release.

3. Execution — Three-stage credential stealer (204-line entrypoint.sh). Malicious entrypoint.sh SHA256: 18a24f83e807479438dcab7a1804c51a00dafc1d526698a66e0640d1e5dd671a. Lines 4–105: infostealer. Lines 106–204: legitimate Trivy scan. Scan runs normally after the stealer, so pipeline output looks clean.

Stage 1 — Collection: GitHub-Hosted vs Self-Hosted Runners

On GitHub-hosted Linux runners, the malware uses passwordless sudo to dump Runner.Worker process memory via /proc/[pid]/mem, searching for the JSON pattern {“value”:”<secret>”,”isSecret”:true} stored in the .NET process heap.

On self-hosted runners, a comprehensive Python filesystem credential harvester targets the following categories:

Stage 2 — Encryption

Collected data is encrypted with AES-256-CBC (key derived via PBKDF2 from 32 random bytes). The session key is wrapped with an embedded RSA-4096 public key using OAEP padding. Both files bundled into tpcp.tar.gz. Only the RSA private key holder can decrypt.

Stage 3 — Exfiltration

Primary: HTTPS POST to scan.aquasecurtiy[.]org (45.148.10.212) with header X-Filename: tpcp.tar.gz. Fallback: if C2 unreachable and INPUT_GITHUB_PAT available, creates public tpcp-docs repo on victim’s GitHub account and uploads the bundle as a release asset with timestamped tag (data-YYYYMMDDHHMMSS). Data stored on GitHub’s own infrastructure — unlikely to be blocked by corporate firewalls.

The “Immutable” Badge Deception

GitHub’s release UI displayed an “Immutable” badge on each poisoned tag. The attacker appears to have published immutable releases when poisoning the tags, locking in the malicious state. Each poisoned tag showed “0 commits to master since this release” — for a tag from 2020, this should show hundreds. The count was zero because the malicious commit’s parent was master HEAD.

CanisterWorm Cascade into npm

Stolen npm tokens triggered a follow-on attack. TeamPCP injected CanisterWorm into 47+ npm packages via ICP canister dead-drop C2. A newer variant self-propagates during postinstall by harvesting npm tokens. Persistence via systemd user service masquerading as “pgmon”.

Affected Versions

Exposure Analysis

Detection Guidance

Indicators of Compromise

Forgery Detection Indicators

• Unsigned commits: original Trivy releases were GPG-signed by GitHub. Replacement commits are unsigned.
• Impossible timestamps: forged commits clone original dates (2021–2024) but parent is dated March 2026.
• Single-file modifications: each malicious commit only modifies entrypoint.sh (tree is master HEAD, not original).
• “0 commits to master since this release” on GitHub release page for tags that should show hundreds of commits.

Verification Steps

1. Search workflow files: grep -r “aquasecurity/trivy-action” .github/workflows/
2. Check if any workflow ran a version-tag reference (not SHA) between March 19 17:43 UTC and March 20 05:40 UTC
3. Check self-hosted runners for ~/.config/sysmon.py and pgmon.service
4. Search GitHub org for tpcp-docs repositories (indicates successful exfiltration)
5. Run StepSecurity trivy-compromise-scanner for automated log auditing

Detection Campaign

A Phoenix campaign has not been generated because this was a compromise of a specific version of Trivy,

setup-trivy to safe version v0.2.6

Remediation Guidance

Immediate Actions

6. Pin trivy-action to SHA: aquasecurity/trivy-action@57a97c7e7821a5776cebc9bb87c984fa69cba8f1
7. Pin setup-trivy to safe version v0.2.6
8. Rotate all pipeline secrets if any workflow ran a compromised tag during the exposure window
9. Block scan.aquasecurtiy[.]org, 45.148.10.212, and plug-tab-protective-relay.trycloudflare.com
10. Search GitHub org for tpcp-docs repositories and audit self-hosted runners for persistence

Long-Term Hardening

• Pin all GitHub Actions to full SHA hashes (zizmor, pinact, StepSecurity secure-repo, Renovate pinGitHubActionDigests)
• Audit all pull_request_target workflows — if it checks out PR head code, it is vulnerable
• Minimise token permissions; prefer read-only tokens with narrowest scope
• Enable immutable releases on repositories publishing GitHub Actions
• Require GPG-signed commits for release tags

Phoenix Security Recommendations

The Trivy compromise demonstrates why vulnerability management cannot stop at scanning known CVEs. This attack had no CVE, no CVSS score, no NVD entry. Traditional scanner-based workflows would not have flagged it.

Attack surface management: Phoenix identifies CI/CD pipelines running compromised components and maps whether references use mutable tags or immutable SHAs.

Contextual deduplication: Organisations using Trivy across dozens of repositories get a single prioritised backlog rather than duplicate alerts per repository.

Reachability analysis: Phoenix maps which instances actually executed compromised code versus those merely declared in workflow files.

Remediation campaigns: Create a campaign in Phoenix to track SHA migration, secret rotation, and runtime exposure elimination.

Ownership attribution: Map each affected workflow to the owning team for coordinated response across hundreds of repositories.

Appendix: Full List of Compromised trivy-action Tags

All 75 compromised tags with their malicious commit SHAs (source: Socket Security). The only clean tag is 0.35.0 (commit 57a97c7e).

If your workflow references any of the above tag@SHA combinations, it was executing malicious code.

Timeline

Reference

This article relies on the fantastic contributions of the community and great researchers

• Acqua Sec Official Advisory
• Open Source Malware – Teampcp aquasec github compromise
• Socket.dev – Trivy Under Attack Again: GitHub Actions Tag Compromise
• Aikido Security – TeamPCP deploys CanisterWorm on NPM
• Aikido Security – CanisterWorm Gets Teeth: TeamPCP’s Kubernetes Wiper Targets Iran

How Phoenix Security Fixes What Actually Matters

Your team doesn’t have a finding problem. They have a fixing problem.

Most platforms hand you a list. Phoenix hands you a plan — ranked by real risk, mapped to the team that owns it, with a clear path to close it.

What remediation looks like with Phoenix:

• One backlog, not five. Findings from SAST, SCA, containers, and cloud — deduplicated, correlated, and surfaced in a single prioritized queue. No more reconciling lists across tools.
• Ownership that sticks. Team attribution and inheritance mean the right ticket goes to the right engineer, first time. No routing, no guessing, no back-and-forth.
• Campaigns that move the needle. Group related findings into targeted remediation campaigns. Track progress, measure closure rates, and report real reduction — not raw counts.
• AI that does the legwork, not the deciding. Phoenix’s Remediator agent drafts fixes, creates tickets, and opens PRs. Your team reviews, approves, and merges. Every fix is traceable.

Phoenix Security changes the game.

The results are clear:

• Bazaarvoice saved $6.3M in developer time and for teams removed critical in the first weeks of adoption
• ClearBank cut critical container vulnerabilities by 96–99% and reclaimed 4 hours per engineer per week.
• IAS saved an equivalent of 1.5M in development hours and reduced SCA-to-container noise by 82.4%
• Optimizely has been able to act on vulnerabilities sitting on the backlog.

The pattern is the same every time: teams that move from find and report to analyze and fix close more risk with less effort.

The results are clear:

• Bazaarvoice saved $6.3M in developer time and for teams removed critical in the first weeks of adoption
• ClearBank cut critical container vulnerabilities by 96–99% and reclaimed 4 hours per engineer per week.
• IAS saved an equivalent of 1.5M in development hours and reduced SCA-to-container noise by 82.4%
• Optimizely has been able to act on vulnerabilities sitting on the backlog.

👉 Book a demo today

Or learn how Phoenix Security slashed millions in wasted dev time for fintech, retail, and adtech leaders.

Fix with remediaiton don’t chase ghost vulnerabilities

Get Fixing today