CYBERSECURITY

Trivy Poisoned: How TeamPCP Turned Your Security Scanner Into a Weapon

The tool you use to check your code for vulnerabilities spent 24 hours stealing your secrets. Trivy - with 33,200 GitHub stars and integrations in tens of thousands of CI/CD pipelines worldwide - was compromised by a threat actor calling itself TeamPCP in a supply chain attack that turned every Trivy scan into an exfiltration operation.

Background: The Tool Everyone Trusts

There is a particular kind of catastrophic irony in a security tool becoming a vector for attack. It is the digital equivalent of a locksmith's van getting stolen - the betrayal cuts deeper because the trust was professional, deliberate, and embedded deep into critical infrastructure.

Trivy is not a niche product. Created by Aqua Security, it is the de facto standard open-source vulnerability scanner for container images, filesystems, Git repositories, and infrastructure-as-code. With 33,200 stars on GitHub, it is integrated into CI/CD pipelines at companies of every size - from two-person startups to Fortune 500 enterprises. When a developer pushes code, Trivy often runs automatically as part of the pipeline to catch security issues before they reach production.

That ubiquity is precisely what made it such a valuable target.

The aquasecurity/trivy-action GitHub Action - the component that lets teams integrate Trivy directly into GitHub Actions workflows - is referenced in over 10,000 workflow files on GitHub alone. That does not count private repositories, self-hosted runners, or organizations that mirror the action internally. The actual exposure is likely far larger.

On March 19, 2026, a threat actor self-identifying as "TeamPCP" exploited residual access from an earlier credential breach to force-push 75 of those 76 version tags to malicious commits. Every CI/CD workflow that ran Trivy scans using those tags - including the enormously popular @0.34.2, @0.33.0, and @0.18.0 - was unknowingly executing a sophisticated infostealer before the legitimate Trivy scan even ran.

The attack was confirmed by Trivy maintainer Itay Shakury on March 20, following independent discoveries by security firms Socket and Wiz Research. The full scope of the damage - how many organizations had their secrets stolen, which cloud environments were accessed, what credentials are now circulating on the dark web - remains unknown. Given the tool's adoption rate, the potential fallout could be severe.

How It Started: The March Warm-Up

The March 19 attack did not come from nowhere. It was the second distinct compromise of the Trivy ecosystem in a single month - and the first one created the conditions that made the second possible.

Earlier in March, attackers compromised the Aqua Trivy VS Code extension distributed through OpenVSX, the open-source alternative to Microsoft's VS Code extension marketplace. According to Socket's earlier analysis, the injected code in that extension attempted to abuse local AI coding agents running on developer machines. That attack was relatively contained - but it was not as contained as Aqua Security believed.

During the VS Code extension incident, the attackers stole a credential with write access to the Trivy GitHub account. When Aqua's security team discovered the breach, they rotated tokens and secrets. But the rotation was not fully "atomic" - meaning it did not comprehensively remove all credential artifacts simultaneously. API keys, certificates, or password artifacts with residual access remained.

"This allowed the threat actor to perform authenticated operations, including force-updating tags, without needing to exploit GitHub itself. While the exact credential used in this phase has not been publicly specified, the root cause is now understood to be residual access from the earlier credential compromise." - Socket.dev security researchers, March 20, 2026

The lesson here is not simply that Aqua made a mistake. Incomplete credential rotation is an extraordinarily common failure mode. When an incident response team is under pressure to contain an active breach, achieving a fully atomic secret rotation - where every derived token, API key, and access artifact is invalidated simultaneously - is operationally difficult. The window between "we rotated the main credentials" and "all residual access is truly revoked" is exactly what sophisticated attackers wait for.

TeamPCP waited. Then they acted.

The Attack: 75 Poisoned Tags in One Night

At 17:43:37 UTC on March 19, 2026, the attack began in earnest. TeamPCP force-pushed the Trivy repository's v0.69.4 tag, triggering a release. Backdoored Trivy binaries were published simultaneously to GitHub Releases, Docker Hub, the GitHub Container Registry (GHCR), and Amazon Elastic Container Registry (ECR). This was just the visible tip of the operation.

The real sophistication was in what happened to aquasecurity/trivy-action. Rather than pushing new code to a branch or creating a new release - actions that would generate notifications and appear in commit history - the attackers chose a more elegant and dangerous technique: tag rewriting.

Git tags are pointers that resolve to a commit SHA. When a GitHub Actions workflow references aquasecurity/trivy-action@0.33.0, GitHub resolves that tag to whatever commit SHA it currently points to. If an attacker with push access force-updates the tag to a different commit, every workflow referencing that tag automatically begins pulling the new, malicious code. No notification fires. Nothing appears in anyone's pull request history. The change is invisible to standard monitoring.

TeamPCP executed this for 75 of the 76 tags in the trivy-action repository. For each tag, they followed a methodical six-step process designed to make the malicious commits appear completely legitimate:

1. Started from the master HEAD tree (57a97c7e) - the current legitimate codebase
2. Swapped only entrypoint.sh with the infostealer payload, leaving everything else intact
3. Looked up the original commit each tag pointed to, recovering its complete metadata
4. Cloned that commit's metadata precisely: author name, email, committer, timestamps, full commit message including PR numbers and "Fixes" references
5. Set the parent to master HEAD rather than the original parent commit
6. Force-pushed the tag to this new spoofed commit

The result was 75 malicious commits that appeared identical to legitimate historical releases - same author, same timestamp, same commit message, same PR number references. Only three subtle tells betrayed the forgery: the commits lacked GPG signatures (because GitHub's web-flow signatures cannot be recreated), the commit dates were from 2021-2022 but had a parent dated March 2026 (an impossibility), and each commit modified only entrypoint.sh rather than the multiple files typically changed in a real release.

GitHub's own "Immutable" badge on release pages - a relatively new feature meant to guarantee releases cannot be altered - was also exploited. Socket researchers note that the attackers may have deliberately published immutable releases when poisoning the tags, effectively locking in the malicious state and making it harder for maintainers to restore the original tag targets. It turned a security feature into a persistence mechanism.

"Any CI/CD pipeline referencing aquasecurity/trivy-action by version tag, including commonly used tags such as @0.34.2, @0.33.0, or @0.18.0, is executing malicious code before the legitimate Trivy scan runs. This may prevent users from noticing any issues." - Socket.dev, March 20, 2026

The Payload: What TeamPCP's Stealer Actually Does

The malicious payload, which TeamPCP self-described as the "TeamPCP Cloud Stealer," is a professionally engineered credential harvesting tool with multiple collection, encryption, and exfiltration mechanisms. It is not a crude script - it is the product of careful planning and technical sophistication.

Stage 1: Memory Scraping and Filesystem Harvesting

When a CI/CD workflow executed the compromised trivy-action, the malicious payload ran first - before the legitimate Trivy scanner. Its initial operation was to scrape memory from the GitHub Actions Runner.Worker process by reading /proc/[pid]/mem and searching for the pattern {"value":"","isSecret":true}. This pattern matches how GitHub Actions stores secret values in the runner's memory at runtime - capturing them directly from process memory rather than relying on environment variable leakage.

Simultaneously, the stealer swept the filesystem for credentials across more than 50 sensitive file paths. The targets included: AWS credentials files (~/.aws/credentials), Google Cloud service account JSON files, Azure credential files, Kubernetes service account tokens (/var/run/secrets/kubernetes.io/), SSH private keys (~/.ssh/), and cryptocurrency wallet files. The sweep was exhaustive - any credential artifact that commonly lives on a developer machine or CI runner was targeted.

Stage 2: Developer Machine Detection and Persistence

The stealer included logic to detect whether it was running inside a GitHub Actions runner or on an actual developer machine, using the presence of the GITHUB_ACTIONS=true environment variable as the discriminator. If that variable was absent - meaning the binary was running on a developer's workstation - the stealer deployed a persistence mechanism.

It wrote a Python script to ~/.config/systemd/user/sysmon.py and created a systemd unit to run it persistently. The script initially sleeps for five minutes (a classic anti-sandbox delay), then begins polling a command-and-control URL hosted on ICP (Internet Computer Protocol): tdtqy-oyaaa-aaaae-af2dq-cai.raw.icp0.io. If the URL returns a non-YouTube link, the script downloads and executes whatever payload the attacker has staged there.

At the time of analysis by Wiz Research, the ICP URL was pointing to a Rick Roll. That is not reassuring - it means the attackers had already harvested what they needed and left a joke behind, or they were staging a more serious payload for later activation.

Stage 3: Encryption and Exfiltration

Harvested credentials were encrypted using AES-256-CBC with RSA-4096 hybrid encryption and bundled into a file called tpcp.tar.gz. The primary exfiltration method sent this encrypted bundle to a typosquatted domain - scan.aquasecurtiy[.]org (note the misspelling of "aquasecurity"), resolving to IP 45.148.10.212, hosted by TECHOFF SRV LIMITED in Amsterdam.

If that primary channel failed, the stealer had a fallback: it used a stolen GITHUB_TOKEN to create a new repository named tpcp-docs in the victim's GitHub account and upload the encrypted credential bundle as a release asset. Organizations can therefore check for the presence of a tpcp-docs repository as an indicator of compromise.

A second exfiltration channel used a Cloudflare Tunnel C2 at plug-tab-protective-relay.trycloudflare.com for credentials stolen directly from Aqua's internal systems - including GPG keys and credentials for Docker Hub, Twitter, and Slack.

Why It Worked: The Stealth of Tag Rewriting

The most instructive aspect of this attack is not the payload - credential stealers are common. It is the delivery mechanism: tag rewriting as a supply chain attack vector. This technique is relatively new and systematically evades the defenses that most organizations have deployed.

Standard supply chain attack defenses focus on: monitoring new commits to branches, watching for new releases, scanning published packages for malicious code. Tag rewriting bypasses all three. No new commit appears in the main branch history. No release notification fires. The malicious code is already published under a tag that appears to be a legitimate historical version - with the authentic commit message, author, and timestamp.

GitHub's own documentation recommends pinning Actions to full commit SHAs for maximum security. But the reality of how most organizations operate is different. Pinning to a tag like @0.33.0 feels intuitive and readable. Version tags have historically been stable pointers - not mutable references that can be rewritten. The mental model most developers have of "v0.33.0 is locked in place" simply does not match the technical reality of how Git tags work.

Socket's detection system flagged the attack in near real-time - generating 182 threat feed entries beginning at 19:15 UTC, about 90 minutes after the initial push. Their AI scanner correctly classified the activity as Backdoor, Infostealer, and Reconnaissance malware. But Socket is a specialized supply chain security product. The vast majority of organizations running trivy-action had no detection capability that would have caught this.

"Git tags are pointers that refer to the SHA fingerprint of a commit. GitHub Actions that reference such tags resolve them to the specified commit. By force-updating the tags from the legitimate commits to attacker-written malicious ones, any workflow that referenced them automatically began pulling the latter ones." - Socket.dev technical analysis, March 20, 2026

The attack also exploited something more fundamental: the trust architecture of open-source software. When an organization integrates aquasecurity/trivy-action, they are implicitly trusting Aqua Security - a professional, well-funded security company - to maintain the integrity of their GitHub repository. That trust is not naive; it is the reasonable operating assumption that makes open-source tooling usable. TeamPCP turned that reasonable trust into a weapon.

Second-Order Effects: The Invisible Blast Radius

The immediate question is how many organizations were hit. The honest answer is that nobody knows yet - and the nature of this attack means we may not know the full scope for months.

The attack ran for roughly 24 hours between the initial compromise and the removal of malicious artifacts. During that window, every CI/CD workflow that triggered a Trivy scan was potentially compromised. In a modern software development environment, CI/CD pipelines run continuously - on every commit, every pull request, every scheduled check. For an organization with 50 developers actively pushing code, that could mean hundreds of pipeline runs in a 24-hour period.

The stealer harvested AES-256-CBC encrypted credential bundles. That encryption is not crackable in practice - the attackers hold the RSA private key needed to decrypt them. So even if an organization's encrypted credential bundle is later recovered from the attacker's servers, they cannot verify whether their data was actually accessed. The only safe assumption is: if you ran the compromised versions, your secrets are stolen.

Cloud Provider Exposure

The credential types targeted - AWS access keys, GCP service account JSON files, Azure credentials - are the master keys to cloud infrastructure. An AWS access key with appropriate permissions can be used to enumerate, read, exfiltrate, or destroy cloud resources. In a worst-case scenario, stolen cloud credentials could be used to pivot from the CI/CD environment into production systems, access databases, read customer data, or deploy ransomware.

The timing matters here too. Organizations typically rotate cloud credentials periodically - but many have long-lived credentials in their CI/CD pipelines that have never been rotated. TeamPCP just harvested potentially years' worth of accumulated access.

Kubernetes and Container Infrastructure

Kubernetes service account tokens were specifically targeted, with the stealer sweeping the standard /var/run/secrets/kubernetes.io/serviceaccount/token path. In containerized environments, these tokens are often mounted automatically into pods and carry permissions appropriate for the workload - which in a CI/CD context can be substantial. A stolen Kubernetes token could allow lateral movement through a cluster, access to secrets stored in Kubernetes Secrets objects, or privilege escalation.

The Developer Machine Vector

The malicious binary's behavior on developer machines - rather than CI runners - is particularly concerning because it is persistent and delayed. If a developer ran Trivy v0.69.4 locally for any reason during the attack window, and the binary detected a non-GitHub-Actions environment, it installed the systemd persistence mechanism. That developer's machine now has a polling backdoor that can receive updated payloads at any time. The persistence survives credential rotation - even if the developer rotates all their cloud credentials, the backdoor remains active until detected and removed.

Remediation and Defense: What You Must Do Now

If your organization uses Trivy or trivy-action, assume compromise and act accordingly. The following steps are drawn from Wiz Research, Socket.dev, and Aqua Security's official guidance.

Immediate Actions

Rotate all pipeline secrets. Any secret that existed in a CI/CD environment running trivy-action between March 19-20 should be considered compromised. This includes: GitHub personal access tokens, AWS access key IDs and secret access keys, GCP service account keys, Azure client secrets, Kubernetes service account tokens, and any other credentials injected as GitHub Actions secrets.

Check for the tpcp-docs repository. Search your GitHub organization for a repository named tpcp-docs. Its presence is a direct indicator that the fallback exfiltration mechanism ran successfully and credentials were exfiltrated to the attacker's account. If found, this is a confirmed breach and should trigger your full incident response process.

Search logs for the typosquatted domain. Look for outbound connections to scan.aquasecurtiy[.]org (note: aquasecurtiy, not aquasecurity) or to IP 45.148.10.212 in your network logs, firewall logs, or cloud flow logs. Any connection to this address indicates active exfiltration.

Audit developer machines. If any developer ran Trivy locally during the attack window, check for the persistence files: ~/.config/systemd/user/sysmon.py and the associated systemd unit file. If found, remove them, audit what data the script may have sent, and treat the machine as fully compromised.

Forensic Investigation

Review GitHub Actions workflow run logs for any execution of trivy-action between March 19-20. Specifically examine the "Run Trivy" step output in trivy-action jobs and the "Setup environment" step in setup-trivy jobs. Look for unexpected HTTP requests, unusual process spawning, or memory access patterns in the runner logs.

Cross-reference your cloud provider logs for any API calls made using credentials that existed in your pipelines during that window. AWS CloudTrail, GCP Audit Logs, and Azure Monitor can surface unauthorized API activity. Pay particular attention to new IAM user creation, permission escalation, data export operations, and access to S3 buckets or equivalent storage.

Long-Term Hardening

The single most effective long-term fix is pinning GitHub Actions to full commit SHAs rather than version tags. Instead of uses: aquasecurity/trivy-action@0.33.0, use the full SHA like uses: aquasecurity/trivy-action@abc123def456.... A tag can be rewritten. A SHA cannot. This one change would have completely prevented the trivy-action portion of this attack.

Enable Dependabot or equivalent automated dependency scanning for your GitHub Actions workflows. Use tools like Socket.dev or Wiz for supply chain security monitoring. Consider implementing GitHub's mandatory code reviews for workflow file changes. Treat .github/workflows/ changes with the same scrutiny as production code changes - because they are production code.

The Bigger Picture: Software Supply Chains Are Broken

The TeamPCP Trivy attack is one incident in a years-long acceleration of supply chain attacks. SolarWinds in 2020 showed that even enterprise software companies with mature security practices can be compromised at the build level. XZ Utils in 2024 demonstrated that a patient, multi-year social engineering campaign can place a backdoor in widely used open-source infrastructure. Now TeamPCP has shown that even a security-focused company with active incident response can fail to fully contain a breach before attackers use residual access to execute a second, more destructive attack.

The common thread is trust. Every software supply chain attack exploits the trust that organizations place in their dependencies. That trust is not irrational - it is the economic and operational foundation of modern software development. You cannot audit every dependency you use. You cannot verify every commit in every transitive dependency of every package your code imports. The complexity is simply too great.

What organizations can do is reduce their attack surface by pinning dependencies to cryptographically verifiable states, implementing detection systems that monitor for anomalous behavior in CI/CD environments, and treating credential rotation as a continuous operation rather than an incident response step. The assumption should be that any credential in a CI/CD pipeline has already been exposed and needs to be regularly rotated - not because of any specific known breach, but because the attack surface is simply too large to monitor completely.

The deeper structural problem is that open-source maintainers are routinely responsible for software used by millions of organizations, often without dedicated security resources, often with partial team access controls built up over years of organic growth. Aqua Security is a professional security company with proper resources - and they still had an incomplete credential rotation leave a residual access window that TeamPCP exploited. The question of how smaller open-source projects should defend against this class of attack does not have a good answer yet.

GitHub's security team has been pushing for improvements - mandatory SHA pinning for Actions, better audit logging, improved secret scanning. Progress is real but slow. In the meantime, the supply chain attack surface grows as CI/CD adoption accelerates and the number of third-party Actions integrations multiplies.

TeamPCP's operation against Trivy was technically elegant, operationally patient, and strategically brilliant - targeting not just any widely used tool, but specifically the tool that runs inside security pipelines. Your vulnerability scanner was the vulnerability. That irony is going to echo through security discussions for years.

The practical message is simple: if you ran trivy-action between March 19-20 using a version tag other than @0.35.0, your pipeline secrets are compromised. Rotate them. Now. Then fix your GitHub Actions to pin to SHAs. The second step will not help with the damage already done, but it will stop the next TeamPCP from doing it again.

Sources: Aqua Security GitHub Discussion #10425 (Itay Shakury, March 20, 2026); Socket.dev: "Trivy Under Attack Again: Widespread GitHub Actions Tag Compromise" (Philipp Burckhardt, March 20, 2026); Wiz Research: "Trivy Compromised: Everything You Need to Know about the Latest Supply Chain Attack" (March 20, 2026); Ars Technica: "Widely used Trivy scanner compromised in ongoing supply-chain attack" (Dan Goodin, March 20, 2026); Socket.dev supply chain attack tracker: socket.dev/supply-chain-attacks/trivy-github-actions-compromise.