Trivy Supply Chain Compromise: How TeamPCP Weaponized a Security Scanner to Steal Credentials Across 10,000 Pipelines + Video

Listen to this Post

Featured Image

Introduction:

The recent compromise of Aqua Security’s Trivy GitHub Actions reveals a sophisticated supply chain attack where attackers exploited a fundamental flaw in the trust model of CI/CD pipelines: mutable Git tags. By force-pushing 76 version tags, the threat actor TeamPCP transformed a trusted vulnerability scanner into a multi-stage credential stealer, demonstrating that when a security tool itself becomes the attack vector, the implications cascade far beyond a single repository.

Learning Objectives:

  • Understand how mutable Git tags enable silent supply chain attacks and the critical importance of immutable SHA references.
  • Identify the indicators of compromise (IOCs) associated with the TeamPCP campaign, including malicious npm packages and exfiltration domains.
  • Implement atomic credential rotation and least-privilege service account policies to mitigate similar CI/CD pipeline vulnerabilities.

You Should Know:

  1. Immutable References vs. Mutable Tags: The Root Cause

The core of this attack lies in the misuse of Git tags as immutable versioning mechanisms. In reality, Git tags are mutable pointers. An attacker with push access can force-push a tag (e.g., v0.69.5) to a different commit hash. When a GitHub Actions workflow references [email protected], it will pull the newly compromised commit without any notification, diff, or alert on the GitHub release page—the “Immutable” badge remains.

To secure your pipelines, you must shift from mutable tags to immutable full SHA hashes.

Step‑by‑step guide:

  1. Inventory Your Workflows: List all GitHub Actions workflows that use third-party actions. Use the GitHub CLI or API.
    Linux/macOS: Extract all uses of actions/checkout and custom actions
    gh api repos/{owner}/{repo}/actions/workflows --paginate | jq '.workflows[].path' | xargs -I {} gh api repos/{owner}/{repo}/contents/{} | jq '.content' -r | base64 -d | grep -E "uses: .+@v[0-9]+.[0-9]+.[0-9]+"
    
  2. Replace Tags with SHAs: Update your YAML workflow files. Locate the `uses:` line and replace the tag with the full 40-character commit SHA of the specific version you intend to use.
    Before (Vulnerable)</li>
    </ol>
    
    - name: Run Trivy scanner
    uses: aquasecurity/[email protected]
    
    After (Secure)
    - name: Run Trivy scanner
    uses: aquasecurity/trivy-action@a1b2c3d4e5f67890abcdef1234567890abcdef12  SHA of v0.69.5
    

    3. Automate SHA Updates: Implement Dependabot or a custom script to update SHAs safely, but ensure the update process includes verification and testing before merging.

    2. Over-Privileged Tokens and Non-Atomic Rotation

    The attacker leveraged a long-lived, over-privileged service account token used across 33 workflows. A misconfigured `pull_request_target` workflow, flagged months prior, allowed the attacker to escalate privileges. The failure in credential rotation was that it was not atomic—meaning tokens were rotated gradually, leaving windows of exposure where compromised tokens remained valid.

    Step‑by‑step guide:

    1. Audit Service Account Tokens: List all service accounts and their associated permissions in your CI/CD environment.
      Using GitHub CLI to list tokens and their last usage
      gh api /orgs/{org}/actions/secrets/public-key
      gh api /repos/{owner}/{repo}/actions/secrets
      
    2. Enforce Least Privilege: Use granular permissions. For GitHub Actions, set permissions at the workflow level to `read-all` and explicitly add `write` only for specific scopes when necessary.
      .github/workflows/secure-build.yml
      permissions:
      contents: read
      issues: write  Only if the workflow needs to comment on issues
      pull-requests: write
      
    3. Implement Atomic Rotation: Atomic rotation means invalidating all instances of a credential simultaneously. Use short-lived tokens and automate rotation.

    – For AWS: Use `aws sts get-session-token` or OIDC integration with GitHub to generate temporary credentials per job.
    – For GitHub: Use GitHub’s built-in `GITHUB_TOKEN` with the minimum required permissions defined in the workflow.
    – Script Example (Linux): Rotating a compromised token via API.

     Revoke all tokens for a user or service account (example for AWS IAM)
    aws iam list-access-keys --user-name compromised-user
    aws iam delete-access-key --access-key-id OLD_KEY_ID --user-name compromised-user
    aws iam create-access-key --user-name compromised-user
    

    3. Detection: Hunting IOCs and Pipeline Anomalies

    The attack was sophisticated because the scan output appeared normal. The malicious code was injected in stages, dumped runner memory, and swept 50 credential paths. To detect this, you must hunt for anomalies in network egress, process memory, and log integrity.

    Step‑by‑step guide:

    1. Monitor for Typosquatted Domains: The exfiltration targeted a typosquatted domain. Use network logs to detect DNS requests to suspicious domains.
      Linux: Parse DNS logs for typosquatting patterns (e.g., security[.]cm instead of security[.]com)
      grep -E "security.[a-z]{2,3}$" /var/log/dns.log | grep -v "security.com"
      
    2. Scan for Public Repo Exfiltration: The attacker used the victim’s own GitHub account as a dead drop. Monitor for unusual repository creation or pushes from CI/CD IP ranges.
      Using GitHub's audit log API
      gh api /orgs/{org}/audit-log --jq '.[] | select(.action=="repo.create" and .actor_ip contains("13.32.0.0/16"))'  Replace with CI/CD IP range
      
    3. Memory Dumping Detection: On self-hosted runners, monitor for processes like `memdump` or `procdump` that are not part of the standard build toolchain.
      Windows PowerShell: Check for suspicious memory dumping processes in event logs
      Get-WinEvent -FilterHashtable @{LogName='Security'; ID=4688} | Where-Object { $<em>.Message -like 'procdump' -or $</em>.Message -like 'rundll32' -and $_.Message -like 'lsass' }
      

    4. CI/CD Pipeline Hardening: Moving Beyond Trivy

    The attack’s cascading effect led to 47+ infected npm packages and the defacement of Aqua’s internal GitHub org. This demonstrates that a single compromised point in the pipeline can lead to a full-scale software supply chain infection.

    Step‑by‑step guide:

    1. Pin All Dependencies: Use exact versions and lock files (package-lock.json, yarn.lock) for all dependencies, including tools like Trivy and npm packages.
    2. Isolate Build Environments: Use ephemeral, isolated runners for each build. Never reuse long-lived runners for sensitive operations.
      GitHub Action using self-hosted runner with cleanup
      runs-on: [self-hosted, linux]
      steps:</li>
      </ol>
      
      - name: Checkout
      uses: actions/checkout@v4
       ... build steps ...
      - name: Cleanup
      if: always()
      run: |
      docker system prune -af
      rm -rf ${{ github.workspace }}/
      

      3. Verify Action Integrity: Before using an action, review the source code and verify the maintainer’s signing key. Use tools like `npm audit` or `safety` to scan for known vulnerabilities in build tools.

      5. Incident Response: Compromised Scanner and Token Revocation

      If you suspect your pipeline has been compromised by the TeamPCP attack, immediate action is required to contain the breach and prevent further access.

      Step‑by‑step guide:

      1. Immediate Isolation: Disable any workflows that reference the compromised tags (v0.69.5, v0.69.6). Suspend the compromised service account tokens.
      2. Credential Rotation: Rotate all credentials that were exposed in the CI/CD environment. This includes cloud provider keys, API tokens, and database passwords.
      3. Forensic Acquisition: Capture memory and disk images of the compromised runners for analysis.
        Linux: Capture memory of a suspicious process (replace PID)
        sudo gdb --batch --pid 1234 --ex 'generate-core-file' --ex 'detach' --ex 'quit'
        
      4. Backdoor Removal: Check for persistent backdoors in the repository, such as new webhooks, deploy keys, or modified workflows.
        List all webhooks in a repository
        gh api repos/{owner}/{repo}/hooks
        List all deploy keys
        gh api repos/{owner}/{repo}/keys
        

      5. Cascading Impact: The npm and GitHub Org Defacement

      The attack didn’t stop at Trivy. The stolen tokens were used to infect 47+ npm packages with `CanisterWorm` and deface Aqua’s internal GitHub organization. This highlights the domino effect of supply chain attacks.

      Step‑by‑step guide:

      1. Scan npm Packages: If your project uses any of the suspicious packages, check for malicious code.
        List all npm packages and check for known malicious signatures
        npm list --depth=0 | grep -E "(package1|package2)"  Replace with IOCs from the attack
        
      2. Monitor GitHub Organizations: Set up alerts for organization-level changes, such as new members, repository visibility changes, or altered settings.
        Using GitHub's audit log to detect suspicious org changes
        gh api /orgs/{org}/audit-log --jq '.[] | select(.action | contains("org.update") or contains("member.add"))'
        

      What Undercode Say:

      • Key Takeaway 1: Trust is an architecture issue, not a tooling issue. The use of mutable tags as version identifiers in CI/CD pipelines creates a critical attack surface that bypasses traditional code review and vulnerability scanning.
      • Key Takeaway 2: The cascading nature of this attack—from a scanner to npm packages to full organization takeover—demonstrates that a single compromised pipeline component can lead to a complete loss of trust in the entire software supply chain.

      The TeamPCP attack is a watershed moment for CI/CD security. It illustrates that security tools are not immune to being weaponized and that the “security scanner” itself can become the most dangerous component in the pipeline. The fundamental lesson is that defense-in-depth must extend to the very mechanisms we use to ensure security—version pinning must be immutable, tokens must be ephemeral, and every pipeline must operate under the assumption that any third-party component could be malicious. Organizations must stop treating CI/CD as an internal trusted network and start securing it with the same rigor as their production environments.

      Prediction:

      This attack will force a paradigm shift in CI/CD security, leading to the deprecation of mutable tag references in major platforms like GitHub Actions in favor of mandatory SHA-based pinning. We will see the rise of “pipeline integrity” as a distinct security domain, with new tooling focused on runtime detection of malicious behavior within build environments. The use of agentic AI in supply chain attacks, as hinted at in this compromise, will become the new normal, where attacks are not just scripted but adaptively target the trust relationships between development tools and infrastructure.

      ▶️ Related Video (76% Match):

      🎯Let’s Practice For Free:

      IT/Security Reporter URL:

      Reported By: Fracipo Supplychain – Hackers Feeds
      Extra Hub: Undercode MoN
      Basic Verification: Pass ✅

      🔐JOIN OUR CYBER WORLD [ CVE News • HackMonitor • UndercodeNews ]

      💬 Whatsapp | 💬 Telegram

      📢 Follow UndercodeTesting & Stay Tuned:

      𝕏 formerly Twitter 🐦 | @ Threads | 🔗 Linkedin | 🦋BlueSky