The Trivy Supply Chain Attack: How Compromised Security Tooling Steals Solana Wallets and Cloud Credentials

Your Security Scanner Is the Attack Vector

On March 19, 2026, Aqua Security's Trivy — used by millions of CI/CD pipelines worldwide to scan for vulnerabilities — became the vulnerability. Threat actors from "TeamPCP" injected credential-stealing malware into official Trivy releases, GitHub Actions, and the setup-trivy action. The malware specifically targets cryptocurrency infrastructure: Solana wallet keypairs, RPC authentication credentials, cloud IAM tokens, and Kubernetes secrets.

This isn't hypothetical. Microsoft Defender for Cloud observed the full attack chain in compromised environments. The malware ran the legitimate Trivy scan after exfiltrating your secrets, so your pipeline looked perfectly normal.

If you run Solana validators, DeFi infrastructure, or any crypto-related CI/CD pipeline that uses Trivy, you may already be compromised.

---

The Attack Chain: From Git Tags to Stolen Keypairs

Phase 1: Hijacking Trusted Tags

The attackers exploited a fundamental Git design feature: mutable tags. Using credentials from a prior, incompletely remediated incident, they force-pushed 76 of 77 version tags in aquasecurity/trivy-action and all 7 tags in aquasecurity/setup-trivy.

Every CI/CD pipeline pinned to a tag (like trivy-action@v1) silently started running attacker-controlled code on its next execution. No alerts. No visible changes in GitHub's UI. No modified release metadata.

# Your workflow BEFORE the attack — already compromised
- uses: aquasecurity/trivy-action@v1  # Tag now points to malicious commit
  with:
    scan-type: 'fs'
    scan-ref: '.'

Simultaneously, a malicious Trivy binary (v0.69.4) was published through official release automation to GitHub Releases and container registries.

Phase 2: Broad-Spectrum Credential Harvesting

Once executed in your CI/CD runner, the malware decodes a base64-encoded Python payload that performs systematic credential theft:

Host Fingerprinting:

hostname && whoami && uname -a && ip addr && printenv

Cloud Credentials (Multi-Provider):

• AWS: Environment variables (grep AWS_), ECS task metadata endpoint (169.254.170.2), EC2 IMDS (169.254.169.254)
• GCP: Environment variables + $GOOGLE_APPLICATION_CREDENTIALS file
• Azure: Environment variables (grep -i azure)

Kubernetes Secrets:

# Reads mounted service account tokens
cat /run/secrets/kubernetes.io/serviceaccount/*
# Attempts full cluster secret dump
kubectl get secrets --all-namespaces -o json

Cryptocurrency Infrastructure (The Part That Matters to Us):

• Searches for Solana wallet variables in environment
• Harvests RPC authentication credentials (rpcuser, rpcpassword)
• Scans .env, .json, .yml, .yaml files for API keys and tokens
• Targets validator keypair files

Everything Else:

• WireGuard VPN configs (wg showconf all)
• SSH auth logs
• Database connection strings (MySQL, PostgreSQL, MongoDB, Redis, Vault)
• Slack and Discord webhook URLs
• npm .npmrc auth tokens

Phase 3: Encrypted Exfiltration

All stolen data gets encrypted with AES-256-CBC + RSA hybrid encryption, bundled into tpcp.tar.gz, and POSTed to the typosquatted domain scan.aquasecurtiy[.]org (note the misspelling of "security").

Then the malware cleans up temp files and launches the legitimate Trivy scan. Your pipeline succeeds. Green checkmark. No indication anything happened.

Phase 4: CanisterWorm Propagation

The stolen npm tokens from Phase 2 feed directly into the CanisterWorm — a self-propagating npm supply chain worm. Using stolen _authToken values, it:

1. Enumerates all packages maintainable by the compromised user
2. Increments patch versions
3. Publishes malicious updates to every package

The worm uses an Internet Computer Protocol (ICP) canister as its C2 — a decentralized backend that's nearly impossible to take down through traditional domain seizure.

---

Why This Is Devastating for Crypto Infrastructure

Solana Validators Are Prime Targets

Solana validators run on cloud infrastructure with:

• Validator keypairs that control staking authority and vote accounts
• RPC endpoints with authentication credentials
• Hot wallets for fee payments and rewards collection
• CI/CD pipelines that often have access to deployment keys

A compromised validator keypair means an attacker can:

• Transfer stake authority (exactly like the Step Finance attack)
• Vote maliciously
• Withdraw staking rewards
• Sign arbitrary transactions

If your validator's CI/CD pipeline used Trivy between March 19-20, your keypairs may be compromised. Rotate immediately.

DeFi Protocol Deployment Pipelines

DeFi teams using Trivy in their deployment pipelines may have exposed:

• Upgrade authority private keys — enabling malicious contract upgrades
• Multisig signer keys — undermining governance security
• Treasury wallet keys — direct fund theft
• API keys to oracle services — enabling price manipulation

The Trust Inversion Problem

The attack specifically targeted security tooling. The logic is devastating: organizations that adopt security scanners are more likely to have valuable secrets in their pipelines. By compromising the scanner, attackers get access to the most security-conscious (and therefore most valuable) targets.

This is the same pattern we saw with the SolarWinds attack in 2020, but applied to open-source DevSecOps tooling that the crypto industry relies on.

---

Immediate Response: Are You Affected?

Step 1: Check Your CI/CD Pipelines

Search your GitHub Actions workflows for any Trivy usage:

# Search all workflow files
grep -r "aquasecurity/trivy" .github/workflows/
grep -r "trivy-action" .github/workflows/
grep -r "setup-trivy" .github/workflows/

If found, check your pipeline execution logs between March 19-20, 2026. Any run during this window should be considered compromised.

Step 2: Audit Trivy Binary Versions

# Check installed Trivy version
trivy --version

# If v0.69.4, you're running the compromised binary
# Verify binary hash against known-good checksums
sha256sum $(which trivy)

Step 3: Rotate ALL Credentials

If you were affected, rotate everything — not just crypto keys:

Solana-Specific:

# Generate new validator keypair
solana-keygen new -o ~/new-validator-keypair.json

# Generate new vote account keypair
solana-keygen new -o ~/new-vote-keypair.json

# Transfer stake authority to new keys
solana stake-authorize <STAKE_ACCOUNT> \\
  --new-stake-authority <NEW_AUTHORITY> \\
  --stake-authority <OLD_KEYPAIR>

Cloud & Infrastructure:

• Rotate all AWS IAM credentials and session tokens
• Rotate GCP service account keys
• Rotate Azure service principal credentials
• Rotate Kubernetes service account tokens
• Regenerate all API keys found in .env files
• Rotate database credentials
• Revoke and regenerate npm tokens

Step 4: Check for CanisterWorm Propagation

If your npm tokens were stolen, check if your packages were compromised:

# Check recent publish activity for your packages
npm audit signatures
npm info <your-package> time --json | tail -5

# Look for unexpected patch version bumps
# between March 19-25, 2026

---

Long-Term Defenses for Crypto CI/CD Pipelines

1. Pin GitHub Actions by Commit SHA, Not Tags

Tags are mutable. Commit SHAs are not. Always pin to full commit hash:

# ❌ VULNERABLE: Tag can be force-pushed
- uses: aquasecurity/trivy-action@v1

# ✅ SAFE: Immutable reference
- uses: aquasecurity/trivy-action@a23d3ffc8a3ca6cf58f3cbaa9b12c3a99aa52d86

Use StepSecurity's Harden-Runner or Dependabot's SHA pinning to automate this.

2. Isolate Crypto Keys from CI/CD

Never let deployment pipelines have direct access to private keys:

Architecture:
├── CI/CD Pipeline (Trivy, tests, builds)
│   └── Has: Read-only access, test credentials only
│   └── Does NOT have: Private keys, RPC auth, treasury access
│
├── Signing Service (Isolated)
│   └── Hardware-backed key storage (AWS CloudHSM, GCP Cloud KMS)
│   └── Accessed only via authenticated API calls
│   └── Audit-logged and rate-limited
│
└── Deployment (Separate Pipeline)
    └── Uses signed artifacts from CI/CD
    └── Accesses signing service for transaction signing
    └── Never stores keys in environment variables

3. Use Ephemeral CI/CD Runners

Never run crypto-related CI/CD on persistent runners:

# GitHub Actions already uses ephemeral runners by default
# For self-hosted runners, ensure they're rebuilt per-job:
runs-on: self-hosted
container:
  image: ubuntu:24.04  # Fresh container per run
  options: --rm        # Destroyed after job

Self-hosted runners that persist between jobs accumulate credentials and state that attackers can harvest.

4. Network Egress Controls

Block unexpected outbound connections from CI/CD runners:

# StepSecurity Harden-Runner example
- uses: step-security/harden-runner@v2
  with:
    egress-policy: audit  # Start with audit, then switch to block
    allowed-endpoints: >
      github.com:443
      registry.npmjs.org:443
      # Explicitly allow only needed endpoints

The Trivy malware exfiltrated to scan.aquasecurtiy[.]org — an egress allowlist would have blocked this.

5. Monitor for Anomalous Key Usage

Set up alerts for unexpected operations on your crypto infrastructure:

# Solana: Monitor for unexpected stake authority changes
import asyncio
from solana.rpc.websocket_api import connect

async def monitor_stake_changes():
    async with connect("wss://api.mainnet-beta.solana.com") as ws:
        await ws.account_subscribe(
            STAKE_ACCOUNT_PUBKEY,
            commitment="confirmed"
        )
        async for msg in ws:
            # Alert on any stake authority change
            check_authority_change(msg)

6. Verify Binary Integrity Before Execution

For any security tool in your pipeline, verify checksums against a separate trust anchor:

# Download Trivy with verification
TRIVY_VERSION="0.69.5"  # Known-good version
curl -sfL https://raw.githubusercontent.com/aquasecurity/trivy/main/contrib/install.sh | \\
  sh -s -- -b /usr/local/bin "v${TRIVY_VERSION}"

# Verify with cosign (if available)
cosign verify-blob --certificate trivy.cert --signature trivy.sig trivy

---

The Bigger Picture: Supply Chain Attacks on Crypto

This isn't an isolated incident. The pattern of weaponizing developer tooling against crypto infrastructure is accelerating:

Date	Attack	Crypto Impact
Mar 2025	Glassworm/ForceMemo	Solana memo C2, validator keypair theft
Nov 2025	Glassworm v2	Expanded npm package poisoning
Jan 2026	Glassworm v3	VS Code extension compromise
Mar 2026	Trivy/CanisterWorm	CI/CD pipeline credential theft, Solana wallet targeting

The attackers understand that crypto developers and validators have the highest-value secrets in their development environments. Every build pipeline that touches private keys is a target.

The uncomfortable truth: Your smart contracts can be formally verified, your protocol can pass 18 audits (like Resolv did), and your code can be flawless. None of it matters if an attacker steals your deployment keys from a compromised npm install or trivy scan.

---

Checklist: Is Your Crypto CI/CD Supply-Chain Hardened?

• [ ] All GitHub Actions pinned by commit SHA (not tags)
• [ ] Private keys never stored in CI/CD environment variables
• [ ] Signing operations use hardware-backed key management (HSM/KMS)
• [ ] CI/CD runners are ephemeral (destroyed after each job)
• [ ] Network egress restricted to allowlisted endpoints
• [ ] Binary integrity verified via checksums/signatures before execution
• [ ] npm tokens scoped to minimum required permissions
• [ ] Dependency lockfiles committed and enforced (npm ci, not npm install)
• [ ] Real-time monitoring on stake authority, upgrade authority, and admin key usage
• [ ] Incident response plan covers supply chain compromise scenarios

If you score less than 7/10, your crypto infrastructure is vulnerable to the next TeamPCP campaign — and it's coming.

---

Key Takeaway

The Trivy compromise is the crypto industry's SolarWinds moment. A trusted security tool was weaponized to steal the exact credentials attackers need to drain wallets, hijack validators, and compromise DeFi protocols. The attack was invisible — pipelines passed, scans completed, and secrets left through encrypted channels.

The fix isn't just "update Trivy." It's rethinking how crypto infrastructure interacts with CI/CD pipelines. Keys must be isolated. Runners must be ephemeral. Dependencies must be pinned. And every tool in your build chain — especially the security tools — must be verified before execution.

Your scanner shouldn't be your biggest vulnerability.

---

This is part of the DeFi Security Research series. Previous articles covered calldata injection attacks, Step Finance's OpSec failure, and mutation testing with Slither.