Earlier this year, the Trivy incident showed that security tooling itself can become part of the software supply chain attack surface.

For those unfamiliar with the tool, Aqua Security's Trivy is a widely-used open-source vulnerability scanner. At the time of the breach, more than 10,000 GitHub workflow files referenced it directly. 

On March 19, 2026,, a threat group calling itself TeamPCP pushed a malicious release of Trivy that quietly harvested credentials from affected pipelines that ran the compromised version, then used those credentials to spread further. 

To affected teams, nothing looked obviously broken: the scanner still ran, the pipeline continued, and the malicious activity was hidden behind a normal-looking result.

‍

The attackers didn't break in through a forgotten server or a phishing email. They turned a pipeline security dependency into the delivery mechanism. 

So how did it happen, and what does it tell us about detecting what comes after a supply chain compromise?

‍

How the compromise started

The groundwork for the March 19 attack was laid weeks earlier:

• Late February 2026: Someone exploited a misconfiguration in Trivy's GitHub Actions environment and stole a privileged access token.
• March 1, 2026: After Aqua Security discovered the intrusion, they disclosed it and rotated credentials in response. However, the rotation was incomplete, and a handful of compromised credentials stayed valid.
• March 19, 2026: TeamPCP used that leftover access to force-push a malicious version tag, v0.69.4, to the Trivy repository.

Incomplete containment is a recurring issue in incident response. Partial remediation leaves a door open, and attackers are patient enough to come back through it.

‍

How the Attack Unfolded

That incomplete containment set the stage for a five-phase campaign

‍

1. ‍Repository takeover and tag poisoning:
   
   • TeamPCP compromised two related pieces of the Trivy ecosystem: the scanner itself and the GitHub Action teams use to run it in CI/CD.
   • The malicious v0.69.4 tag triggered Trivy's automated release pipeline, pushing backdoored binaries to GitHub Releases, Docker Hub, GHCR, and Amazon ECR.
   • In the separate trivy-action repository, 75 of 76 version tags were force-pushed to point at malicious code.
   • Organizations using mutable references like @v0.28.0 were redirected to the attacker's code without changing a single line of their own workflow files.
2. Credential harvesting at scale :
   
   • Poisoned actions read directly from GitHub Actions runner memory through /proc/<pid>/mem, bypassing log masking.
   • AWS, GCP, and Azure keys, SSH keys, Kubernetes tokens, and Docker registry secrets were harvested‍
3. Encrypted exfiltration‍
   
   • The stolen data was wrapped in AES-256-CBC and RSA-4096, so inspecting it on the wire told defenders nothing, then sent to a typosquatted domain, scan.aquasecurtiy[.]org. Notice that the i and t in "security" are transposed. 
   • If direct exfiltration failed, the malware had another path: It used the victim's own GitHub token to create a public tpcp-docs repository and staged the encrypted archive there, making the activity look like ordinary GitHub usage.
4. Persistence through disguised monitoring services‍
   
   • On developer workstations, the binary dropped a systemd service disguised as ordinary monitoring tooling — sysmon.py or pgmon — that polled a command-and-control server roughly every 50 minutes.
   • That C2 wasn't a conventional server. It used an Internet Computer Protocol (ICP) blockchain canister: decentralized infrastructure with no registrar to call and no domain to take down.‍
5. CanisterWorm
   
   • With stolen npm tokens in hand, TeamPCP pushed the campaign into the npm ecosystem, compromising more than 47 packages. Later versions used the postinstall hook to steal tokens and publish malicious updates — turning each affected developer machine or CI pipeline into another distribution point. 28 packages were compromised in under 60 seconds.

‍

Lesson 1: Egress is where the attack becomes visible

‍

In a conventional breach, defenders ask: how did the attacker get in? The Trivy attack flips this : the entry was via a trusted tool. The more important question becomes: where did the stolen data go, and how did the attacker maintain access after the initial compromise?

Both answers lived in the network layer:

1. The credential exfiltration went to scan.aquasecurtiy[.]org , a domain that had never appeared in any of the affected organizations' normal outbound traffic.
2. The backdoor beaconed to an ICP blockchain canister on a precise 50-minute interval, which is exactly the kind of periodic, low-volume connection that looks like nothing until you compare it against what that workload normally does.

Egress control isn't about blocking all outbound traffic. It's about knowing what normal looks like for every workload and surfacing the first deviation. 

‍

Lesson 2: Behavioral monitoring catches what signatures miss

‍

The most durable lesson from Trivy isn't about patching or key rotation - it's about the class of detection that would have surfaced this attack regardless of which tool was compromised.

That class has two layers, and both were visible in this attack.

‍

The network baseline

Long before any credentials were used, a runner connected to a domain it had never reached. 

A process initiating a periodic beacon on a precise 50-minute interval to infrastructure that had never appeared in the environment's network history. 

None of this required knowing the attacker's playbook in advance. It required knowing what normal outbound behavior looked like for that workload — and alerting the moment it changed.

‍

The identity baseline

The stolen credentials were used within hours. Before attempting anything destructive, the attacker validated every key using live API calls to confirm which ones were still active. Then came the discovery sweep: IAM enumeration to map users and roles, EC2 to inventory compute, S3 to list every bucket, Secrets Manager to catalog what else could be extracted. Those credentials had never made those API calls before, and they were coming from source IPs that had never been observed before.

None of this required a threat intelligence feed. It required knowing what that identity normally does, and a system that fires when it doesn't.

‍

‍

Lesson 3: Least privilege determines how bad it gets

Even when attackers obtain valid cloud credentials, the damage they can do is almost entirely determined by what those credentials were permitted to do in the first place. 

In the Trivy attack, CI/CD service accounts in most affected environments held far broader permissions than their actual job required, and that gap is what turned a stolen key into a launchpad for IAM enumeration, S3 bulk access, and Secrets Manager extraction.

Scoping every cloud identity to the minimum permissions it genuinely needs doesn't just reduce blast radius, it makes post-compromise activity detectable by nature, because any action outside that narrow scope is by definition anomalous. 

Least privilege isn't just a compliance checkbox.  It's what determines whether a stolen key is a crisis or a contained, recoverable incident. 

‍

‍