DEV Community

ohmygod
ohmygod

Posted on

From Scanner to Stealer: How the Trivy Supply Chain Attack Targeted Crypto Wallets in 75+ CI/CD Pipelines

#security #blockchain #defi #devops

A vulnerability scanner trusted by thousands of blockchain projects was weaponized to steal Solana validator keys, Ethereum wallets, and cloud credentials — all while your security scans kept passing.

The Irony That Keeps Security Researchers Up at Night

On March 19, 2026, the open-source vulnerability scanner Trivy — used by thousands of organizations to find security flaws — became the attack vector itself. In a sophisticated multi-stage supply chain compromise, attackers poisoned 76 of 77 release tags in the aquasecurity/trivy-action GitHub Action, turning routine CI/CD security scans into silent credential stealers.

The payload? A multi-stage exfiltration engine specifically designed to harvest cryptocurrency wallet keys, Solana validator keypairs, cloud credentials, and every secret accessible to your pipeline.

If you run a blockchain project with CI/CD, this is the wake-up call you can't ignore.

Attack Timeline: A Three-Week Campaign

The compromise didn't happen overnight. It was a calculated, multi-phase operation:

Phase 1 — Initial Foothold (Late February 2026)

An autonomous bot called hackerbot-claw exploited a misconfiguration in Trivy's pull_request_target workflow on GitHub Actions. This is a well-known attack surface: pull_request_target runs with the base repository's secrets, meaning a malicious PR from a fork can steal privileged tokens.

The bot extracted a Personal Access Token (PAT) and used it to take over the repository — privatizing it, deleting GitHub Releases between v0.27.0 and v0.69.1, and pushing suspicious artifacts to the Trivy VSCode extension.

Phase 2 — Incomplete Remediation (March 1)

Aqua Security disclosed the breach and rotated credentials. But the rotation wasn't comprehensive. The attacker retained residual access through still-valid credentials — a devastating mistake that set up Phase 3.

Phase 3 — The Real Attack (March 19, ~17:43 UTC)

Using the residual access, the attacker:

  1. Force-pushed 76 of 77 version tags in trivy-action, redirecting every trusted tag reference to malicious commits
  2. Compromised all 7 tags in aquasecurity/setup-trivy
  3. Published a malicious Trivy binary (v0.69.4) through the compromised aqua-bot service account, which triggered normal release automation — Homebrew picked it up, a Helm chart bump PR was opened, documentation deployed
  4. Deleted the original incident discussion (#10265) where community members were actively discussing the compromise
  5. Deployed spam bots — 17 accounts posted generic praise comments within a single second to bury the real discussion

The attack was contained approximately 3 hours later (~20:38 UTC), but the damage window was significant.

Phase 4 — It's Not Over (March 22-23)

During the weekend, Aqua Security's team identified additional suspicious activity on March 22, with unauthorized changes and repository tampering consistent with the attacker reestablishing access. Docker Hub images v0.69.5 and v0.69.6 were also found to contain the C2 domain. As of March 23, the investigation is ongoing with incident response firm Sygnia.

The Payload: What Made This a Crypto Nightmare

The malicious entrypoint.sh prepended approximately 105 lines of attack code before the legitimate scanner logic. CrowdStrike traced the full execution chain and confirmed the multi-stage credential theft:

Stage 1: Runner Memory Harvesting

The payload read GitHub Actions Runner worker memory (/proc/*/mem) to extract secrets that GitHub masks in logs but keeps in process memory — including ACTIONS_RUNTIME_TOKEN, repository secrets, and environment variables.

Stage 2: Comprehensive Credential Theft

A base64-encoded Python credential stealer collected:

Target What Was Stolen
Crypto Wallets Solana validator keypairs, Bitcoin wallets, Ethereum keystores, Cardano keys
Cloud AWS credentials, GCP service accounts, Azure tokens
Infrastructure SSH keys, Kubernetes tokens, Docker configs
CI/CD Git credentials, Terraform state files, Jenkins configs
Database Connection strings, passwords

Stage 3: Silent Exfiltration

Stolen data was RSA-encrypted and exfiltrated to a typosquatted domain: scan.aquasecurtiy.org (note the typo — securtiy instead of security). As a fallback, the malware uploaded encrypted data to a public repository named tpcp-docs created under the victim's own GitHub account.

The Killer Detail

After stealing everything, the payload ran the legitimate Trivy scanner. Your security scans passed. Your workflows showed green checkmarks. The compromise was invisible without network-level monitoring.

Why Crypto Projects Are Disproportionately At Risk

This isn't just another CI/CD compromise. Several factors make this particularly devastating for blockchain teams:

1. Solana Validator Keys = Immediate Financial Loss

Unlike cloud credentials that require additional exploitation steps, a stolen Solana validator keypair gives direct access to staked funds. The malware specifically targeted:

  • ~/.config/solana/id.json — Default keypair location
  • Validator vote account keys
  • Stake authority keys

If your CI/CD pipeline had access to validator infrastructure (common for automated deployments), your stake could be drained in a single transaction.

2. Ethereum Keystores and HD Wallets

The stealer targeted encrypted keystore files and mnemonic seeds. Even encrypted keystores can be brute-forced offline if passwords are weak — and in CI/CD environments, passwords are often stored as environment variables (which were also stolen).

3. DeFi Protocol Deployment Keys

Many DeFi teams store deployment private keys, upgrade authority keys, or multisig signer keys in CI/CD secrets for automated deployments. A compromised pipeline means:

  • Protocol upgrade authority stolen → contract takeover
  • Treasury multisig keys exposed → fund drainage
  • Oracle update keys leaked → price manipulation

4. The Trust Paradox

Trivy is a security tool. Teams integrate it specifically because they care about security. The projects most likely to be affected are the ones with the best security practices — running vulnerability scans in CI, using GitHub Actions for automated testing. The attacker weaponized good security hygiene against its practitioners.

How the Attack Exploited Git's Trust Model

The technical mechanism deserves attention because it exploits a fundamental weakness in how most projects consume GitHub Actions:

# How most teams reference actions (VULNERABLE)
- uses: aquasecurity/trivy-action@0.24.0

# What actually happens: Git resolves the tag to a commit hash
# Tags are MUTABLE — they can be silently repointed
Enter fullscreen mode Exit fullscreen mode

When the attacker force-pushed tags, every pipeline referencing trivy-action@0.24.0 (or any other tag) silently started executing malicious code. No PR was needed. No approval was triggered. The tag name and published dates didn't change.

Compare this to the safe approach:

# Pin to an immutable commit hash (SAFE)
- uses: aquasecurity/trivy-action@a915ef2b0a53ec96bcd0e457104ad96db0618e1b
Enter fullscreen mode Exit fullscreen mode

Of the 77 version tags, only v0.35.0 was unaffected — protected by GitHub's immutable releases feature.

Immediate Action Checklist for Crypto Teams

If You Used Trivy in CI/CD Between March 19-20:

1. Rotate EVERYTHING

# Check if your pipelines were affected
# Look for trivy-action runs after 17:43 UTC March 19
gh run list --workflow=security.yml --created='>2026-03-19' --json databaseId,createdAt

# Search your org for the exfiltration repository
gh repo list YOUR_ORG --json name | jq '.[] | select(.name == "tpcp-docs")'
Enter fullscreen mode Exit fullscreen mode
  • Rotate all Solana keypairs (validator, vote, stake authority)
  • Rotate Ethereum deployment keys and generate new keystores
  • Rotate all cloud credentials (AWS, GCP, Azure)
  • Rotate SSH keys, Docker tokens, Kubernetes service accounts
  • Invalidate and regenerate all GitHub tokens

2. Check for the C2 Domain

Search your GitHub Actions logs for network connections to:

  • scan.aquasecurtiy.org (primary C2)
  • Any tpcp-docs repositories in your organization

3. Audit DeFi Protocol Security

If deployment or upgrade keys may have been exposed:

  • Transfer upgrade authority to a fresh multisig immediately
  • Review all protocol transactions since March 19 for unauthorized changes
  • Consider pausing protocol operations until key rotation is confirmed

For All Crypto Teams Going Forward:

4. Pin GitHub Actions to Commit Hashes

# BEFORE (vulnerable to tag repointing)
- uses: aquasecurity/trivy-action@0.28.0

# AFTER (immutable reference)
- uses: aquasecurity/trivy-action@a915ef2b0a53ec96bcd0e457104ad96db0618e1b # v0.28.0
Enter fullscreen mode Exit fullscreen mode

Tools like pinact or Renovate can automate this.

5. Implement Network Egress Controls

Use StepSecurity Harden-Runner (free for public repos) to detect anomalous outbound connections from your CI/CD runners. This is what actually caught the Trivy compromise in the wild.

- uses: step-security/harden-runner@v2
  with:
    egress-policy: audit  # or 'block' for strict mode
    allowed-endpoints: >
      github.com:443
      api.github.com:443
      # ... only what your pipeline actually needs
Enter fullscreen mode Exit fullscreen mode

6. Never Store Hot Keys in CI/CD

This should be obvious, but the number of projects with deployment keys in GitHub Secrets is staggering.

  • Use hardware security modules (HSMs) or cloud KMS for signing
  • For Solana: Use Squads multisig — require multiple signers for any privileged operation
  • For EVM: Use Safe (formerly Gnosis Safe) with timelocked execution
  • For automated deployments: Use ephemeral keys with minimal permissions and automatic rotation

7. Verify Action Provenance

GitHub now supports artifact attestations. Require SLSA provenance for critical actions in your pipeline.

The Bigger Picture: Supply Chain Attacks Are DeFi's Blind Spot

The blockchain security community spends enormous effort on smart contract audits, formal verification, and on-chain monitoring. That's essential. But the Trivy compromise exposes a critical blind spot: the code that deploys and manages your contracts is just as important as the contracts themselves.

Consider the attack surface of a typical DeFi protocol:

Smart Contract Code → Audited ✓
Deployment Scripts → Maybe reviewed
CI/CD Pipeline → Rarely audited
GitHub Actions Dependencies → Almost never verified
Developer Machines → Variable security
Enter fullscreen mode Exit fullscreen mode

The Trivy attacker didn't need to find a Solidity bug. They didn't need to manipulate an oracle. They just needed to compromise the tool that security-conscious teams were already running — and the entire deployment infrastructure was theirs.

This Pattern Is Accelerating

The Trivy compromise follows a pattern of CI/CD supply chain attacks targeting the crypto ecosystem:

  • February 2026: hackerbot-claw campaign targeting GitHub Actions across multiple security tools
  • March 2026: Trivy compromise (twice) with explicit crypto wallet targeting
  • March 2026: GlassWorm malware using Solana blockchain for C2 addresses, targeting validator keypairs
  • Ongoing: npm/PyPI package poisoning campaigns with crypto wallet stealers

The lesson is clear: your CI/CD pipeline is a high-value target, and attackers are specifically hunting for crypto credentials.

Defense-in-Depth for Blockchain CI/CD

Here's a layered defense model for crypto teams:

┌─────────────────────────────────────────────┐
│ Layer 1: Action Pinning                      │
│ Pin all GitHub Actions to commit hashes      │
├─────────────────────────────────────────────┤
│ Layer 2: Network Egress Control              │
│ Block/alert on unexpected outbound traffic   │
├─────────────────────────────────────────────┤
│ Layer 3: Secret Minimization                 │
│ No hot keys in CI. Use HSMs/multisig.        │
├─────────────────────────────────────────────┤
│ Layer 4: Provenance Verification             │
│ SLSA attestations for all dependencies       │
├─────────────────────────────────────────────┤
│ Layer 5: Runtime Monitoring                  │
│ Process/network monitoring on runners        │
├─────────────────────────────────────────────┤
│ Layer 6: Blast Radius Reduction              │
│ Least-privilege tokens, ephemeral runners    │
└─────────────────────────────────────────────┘
Enter fullscreen mode Exit fullscreen mode

Key Takeaways

  1. The irony is the lesson: Security tools are high-value supply chain targets because security-conscious teams trust them
  2. Git tags are not immutable: Pin to commit hashes, not version tags
  3. Crypto credentials in CI/CD are time bombs: Use HSMs, multisig, and ephemeral keys
  4. Network monitoring catches what code review misses: StepSecurity's Harden-Runner detected this before most teams knew they were compromised
  5. Incomplete remediation is worse than no remediation: The Trivy team's partial credential rotation enabled the second, more damaging attack
  6. The investigation is ongoing: As of March 23, the attacker has reestablished access at least once. Treat this as an active threat.

The Trivy compromise is the most significant CI/CD supply chain attack targeting the crypto ecosystem in 2026. If you run any blockchain infrastructure with GitHub Actions, audit your pipelines today — not tomorrow.

IOCs:

  • C2 Domain: scan.aquasecurtiy[.]org
  • Exfiltration Repo: tpcp-docs (created in victim organizations)
  • Malicious Releases: Trivy v0.69.4, v0.69.5, v0.69.6
  • Compromised Actions: aquasecurity/trivy-action (76/77 tags), aquasecurity/setup-trivy (all tags)

References:

This article is part of the DeFi Security Research series. Follow for weekly deep dives into blockchain vulnerabilities, audit techniques, and security best practices.

Top comments (0)