CanisterWorm is active. Here's what you need to do before tomorrow morning

Last week, the open source security scanner Trivy — used in tens of thousands of CI/CD pipelines worldwide — was compromised. In less than 24 hours, a self-propagating worm called CanisterWorm started spreading through the npm ecosystem. At the time of writing, it has already infected 141 malicious artifacts across more than 66 npm packages. The attack group remains active.

This is not a theoretical supply chain risk. It’s happening right now. And if your pipeline ran Trivy in the last week, you may already be affected.


How We Got Here

On March 19, the threat group known as TeamPCP — previously known for attacking exposed Docker APIs and Kubernetes clusters — exploited compromised credentials to publish malicious versions of Trivy (v0.69.4), trivy-action, and setup-trivy. The backdoored binaries executed a three-stage credential stealer that dumped the Runner.Worker process memory, harvested SSH keys, cloud credentials (AWS, GCP, Azure), Kubernetes tokens, and npm authentication tokens — all while the legitimate scan appeared to run normally.

Those stolen npm tokens were the seed for CanisterWorm. A deploy.js tool allowed the attacker to republish malicious versions of all packages accessible with those tokens. A more recent variant goes further: it self-propagates during postinstall, turning every developer or CI pipeline that installs an affected package into an involuntary propagation vector.

What makes CanisterWorm technically interesting — and dangerous — is its C2 infrastructure. Instead of a traditional web server, the worm queries an Internet Computer Protocol (ICP) canister: a tamper-proof smart contract on the Internet Computer Protocol blockchain. There is no single host to take down, no abuse email to report to. The attacker can rotate the payload at any time by updating a single URL in the canister. At the time of analysis by most researchers, the canister was serving a YouTube rickroll video (dormant state). That can change with a single call.

The attack escalated further. TeamPCP deployed a Kubernetes wiper (kamikaze.sh) targeting Iranian infrastructure, publicly defaced 44 Aqua Security repositories, and published additional malicious images on Docker Hub (0.69.5, 0.69.6) — all using a single compromised service account token that connected two GitHub organizations.


Your Checklist for Today

Here’s what a responsible dev or tech lead should do right now, in this order:

1. Check if you used trivy-action between March 19-21

Search your workflows: grep -r "aquasecurity/trivy-action" .github/workflows/

If any workflow ran a version tag reference (not SHA) between March 19 17:43 UTC and March 20 05:40 UTC, treat that pipeline as compromised.

2. Rotate all credentials that pipeline touched

That includes: npm tokens, AWS/GCP/Azure keys, SSH keys, Kubernetes service account tokens, Docker registry credentials. Don’t wait for confirmation. Rotate now.

3. Pin to the safe versions

  • Trivy: v0.69.3
  • trivy-action: @0.35.0 (SHA: 57a97c7e)
  • setup-trivy: v0.2.6

4. Switch from version tags to SHA pinning for all your GitHub Actions

Version tags can be force-pushed. TeamPCP force-pushed 75 of 76 trivy-action tags. SHA references cannot be manipulated. This is the highest-impact CI/CD hardening change you can make today.

5. Audit your npm publish tokens

If you have packages on npm and your pipeline had access to publish tokens, check if unexpected versions were published. Look for the deploy.js pattern: packages that include it are infected.

6. Check for the “pgmon” systemd service

On self-hosted Linux runners or development machines that ran affected packages, look for a systemd service masquerading as pgmon. That’s CanisterWorm’s persistence mechanism.

7. Review Docker Hub images

If you pull Trivy from Docker Hub, the latest known clean version is 0.69.3. Versions 0.69.4, 0.69.5, and 0.69.6 were malicious and have already been removed — but if those layers are cached in your environment, you need to clean them.


The Structural Problem This Exposes

TeamPCP didn’t break cryptography. They exploited incomplete credential rotation following a previous breach (February 28), a misconfigured pull_request_target workflow that a security tool had flagged three months before it was exploited, and the implicit trust that CI/CD pipelines place in their security tools.

The security scanner was the attack vector. That’s the uncomfortable truth. When a vulnerability scanner becomes the vulnerability, you have a trust model problem — and no amount of scanning solves a trust model problem.

Three structural changes that prevent this class of attack:

Pin Actions to SHAs, not tags. Tags are mutable. SHAs are not.

Apply least privilege to CI/CD tokens. An npm token that can only publish in a specific scope cannot seed a worm across your entire portfolio.

Treat credential rotation as an atomic operation. Rotating some credentials after a breach and not others is equivalent to rotating none.


What’s Next

The ICP canister used as C2 was marked as “unavailable due to policy violation” by the ICP network — but researchers note that the attacker can trivially deploy a new canister. TeamPCP remains active. The worm payload hasn’t yet been fully armed in the wild. That’s not reassuring — it’s a warning.

If you manage a team or pipeline, share this checklist. The cascading nature of this attack means that a single compromised developer token can turn into an outbreak across your entire npm portfolio.


Does your pipeline use trivy-action? Have you already audited the tokens it may have exposed? Let us know in the comments.


References: