One Misconfigured Workflow. Thousands of Compromised Pipelines. Half a Million Stolen Credentials.

Between late February and late March 2026, a threat actor group called TeamPCP executed one of the most damaging software supply chain attacks we've ever investigated. The campaign began with a single misconfigured CI/CD workflow in Aqua Security's Trivy vulnerability scanner - and grew into a multi-ecosystem operation that compromised thousands of downstream pipelines, stole roughly 500,000 credentials, and hit GitHub Actions, Docker Hub, npm, PyPI, and more. The campaign ultimately fed into ransomware operations, with victim data published in April 2026.

‍

Here's how it happened, what made it so effective, and what you should do right now.

‍

How the Attack Worked

‍

It started with a trust problem baked into how GitHub Actions handles pull requests. There's a workflow trigger called pull_request_target that's designed to let maintainers run CI on external contributions. But unlike a normal pull request trigger, it runs with full access to the target repository's secrets. If the workflow also checks out the contributor's code - which Trivy's did - then anyone who opens a pull request gets to run arbitrary code with the keys to the kingdom. (GitHub Security Lab documented this pattern in detail.)

‍

On February 28, an account opened a pull request on a fork of Trivy's repository and immediately closed it. But the workflow had already fired. Running in the trusted context of Aqua Security's org, it silently exfiltrated a service account token with write access to every repository in the organization.

‍

Aqua Security discovered the breach and rotated credentials. But the rotation wasn't atomic - old credentials weren't all revoked at the same instant new ones were issued. The attacker was watching, and captured the replacement tokens during the gap. Three weeks later, they had everything they needed for the next phase.

‍

On March 19, armed with valid credentials, TeamPCP force-pushed 75 of 76 version tags in trivy-action to point to malicious commits. They did the same to setup-trivy and later expanded to Checkmarx's KICS action. Here's the key: any CI/CD pipeline referencing these actions by version tag - the way most teams do it - automatically pulled and executed the attacker's code on its next run. No changes were needed on the victim's side. No pull requests to review. No alerts to investigate. The version tag simply resolved to different code.

‍

The payload was thorough. It scraped runner process memory to extract secrets that GitHub masks in logs but stores in plaintext in runner memory. It swept 50+ file paths for SSH keys, cloud credentials, and Kubernetes tokens. It encrypted everything with AES-256 and RSA-4096, then exfiltrated the bundle to a typosquatted domain designed to look like Aqua Security's own infrastructure. As a fallback, it created repositories on the victim's own GitHub account and uploaded stolen data as release assets - using the victim's infrastructure against them.

‍

During the same campaign, TeamPCP also poisoned Docker Hub images, 47 npm packages in under 60 seconds via a self-replicating payload, the LiteLLM Python package on PyPI, and the Telnyx SDK. Whether each of these traces directly to credentials harvested from the Trivy breach or reflects parallel operations by the same actor is still being investigated - but all are attributed to TeamPCP. (Unit42 covers the full lateral expansion including Checkmarx KICS and AST.)

What Makes This Different

‍

The 3-month warning that went ignored. BoostSecurity's poutine scanner flagged the dangerous pull_request_target workflow configuration in Trivy's repository on November 29, 2025 - three full months before the attack. It was never fixed. Automated security posture checks that surface these misconfigurations before attackers find them aren't optional anymore.

‍

No changes required on victim repos. Because CI/CD pipelines reference GitHub Actions by version tag, force-pushing a tag silently redirects every consumer. Victims didn't merge anything, didn't approve anything, didn't change anything. Their pipelines just ran different code one day. (Wiz's analysis covers how downstream impact propagated.)

‍

What to Do Right Now

‍

Work through these four checks in order. Each one is independent - do all of them regardless of what you find in the others.

‍

1. Check whether you ran compromised versions between March 19-27

‍

This is the most urgent check. If your pipelines ran any of these during the attack window, assume secrets were exfiltrated and rotate immediately.

• First, check which of your repositories reference these actions: run grep -r "aquasecurity/trivy-action\|aquasecurity/setup-trivy\|checkmarx/kics-github-action" .github/workflows/ from each repo root (or search across repos with gh search code "aquasecurity/trivy-action" --owner <your-org>)
• For each matching repository, go to github.com/{owner}/{repo}/actions, filter by date range March 19-27, 2026, and look for any workflow runs that used these actions
• If any match: identify every secret that was accessible to those workflows (repo secrets, org secrets, environment secrets) and rotate all of them - AWS access keys, GCP service account keys, SSH keys, API tokens, everything

2. Enforce SHA pinning for GitHub Actions at the org level

‍

GitHub has a native setting that blocks workflows from running if they reference actions by version tag. Enable it at the org level and it covers all repositories at once.

• Go to GitHub -> Org Settings -> Actions -> General -> Policies
• Enable "Require actions to be pinned to a full-length commit SHA"
• Save - any workflow referencing an action by tag (e.g. @v2, @v0.35.0) will be blocked from running until updated to a full commit SHA

For repository-level enforcement: github.com/{owner}/{repo} -> Settings -> Actions -> General -> same Policies section.

‍

One caveat: this setting applies to regular Actions but not to reusable workflows - those can still be referenced by tag. For the Trivy attack specifically (trivy-action is a regular action), this setting would have prevented it. But reusable workflow references remain a gap.

‍

Existing workflows referencing tags will fail until updated - that is intentional. It forces a review of every third-party action your pipelines depend on. (GitHub docs on this setting)

‍

3. Audit workflows for the dangerous pull_request_target pattern

‍

This is the misconfiguration that enabled Phase 1 of the attack.

• Run: grep -rl "pull_request_target" .github/workflows/ to find affected workflow files
• For each match, check whether the workflow also checks out the PR head: grep -A 30 "pull_request_target" <file> | grep -E "head\.sha|head_ref|pull_request\.head"
• If both are present, the workflow is vulnerable: any external contributor can run arbitrary code in your repository's trusted context with access to your secrets
• Remediation options: (a) remove the ref: pointing to the PR head and check out the base branch instead, (b) move secret-using steps to a separate workflow_run trigger, (c) add a github.event.pull_request.head.repo.full_name == github.repository guard to restrict to non-fork PRs

4. Audit service account PATs for over-privileged scope

‍

A PAT with write access to all repositories is the single highest-risk credential configuration. One stolen token, entire org compromised.

• Go to GitHub -> Org Settings -> Personal access tokens -> Active tokens
• For each active fine-grained PAT: check the Repository access field. Flag any set to "All repositories"
• For those flagged: check the Permissions section. If any permission is write or admin, this token is critical risk
• Remediation: edit the token to restrict to Only select repositories (choose the minimum set needed), and downgrade any write permissions to read where possible
• If a token cannot be scoped down due to operational requirements, document the business justification and ensure it is monitored

How Reco Detects This

‍

When CVE-2026-33634 went public, our research team conducted a proactive threat hunt across every GitHub organization we monitor. We found no indicators of compromise - but we did find over-privileged tokens with write access to all repositories, the exact over-privileged credential configuration that enabled this attack.

‍

We've deployed a new posture policy that flags personal access tokens combining organization-wide scope with write permissions - catching the pre-condition that makes this class of attack possible. We're also expanding our GitHub detection coverage to surface dangerous workflow configurations and anomalous credential usage patterns.

‍

Supply chain attacks exploit trust relationships that most teams never audit. If you'd like to understand your organization's exposure, reach out to our team.

‍

Further Reading

• Wiz: Trivy Compromised by TeamPCP - full incident overview and timeline
• GitHub Security Lab: Preventing Pwn Requests - authoritative explanation of the pull_request_target vulnerability class
• BoostSecurity: 20 Days Later - Trivy Compromise Act II - retrospective on the November 2025 poutine finding that went unaddressed
• Snyk: Trivy GitHub Actions Supply Chain Compromise - tag poisoning mechanics and affected versions
• GitGuardian: Trivy's March Supply Chain Attack - credential exposure mechanics and what was stolen
• Sysdig: TeamPCP Expands to Checkmarx - lateral expansion to Checkmarx AST (ast-github-action v2.3.28)
• Palo Alto Unit42: TeamPCP Supply Chain Attacks - threat actor profile and TTPs
• Microsoft Security Blog: Detecting the Trivy Compromise - detection and response guidance
• Arctic Wolf: TeamPCP Campaign - downstream impact assessment
• GitHub Advisory GHSA-69fq-xp46-6x23 - official advisory with affected versions
• NVD: CVE-2026-33634 - CVE record (CVSS 9.4)