Trivy / Cisco (2026)¶

The Lesson: Your security scanner runs with the keys to the kingdom. When someone compromises the scanner, they inherit all of that access — and your CI/CD pipeline becomes the exfiltration channel.

What Happened¶

In late February 2026, an autonomous bot account called hackerbot-claw — self-described as "an autonomous security research agent powered by claude-opus-4-5" — opened a pull request against aquasecurity/trivy, the most widely used open-source vulnerability scanner in the container ecosystem.¹

The PR exploited a well-documented dangerous pattern in GitHub Actions: Trivy's "API Diff Check" workflow used the pull_request_target trigger, which runs with the base repository's secrets and permissions but can be tricked into checking out attacker-controlled code from a fork. The bot extracted a privileged Personal Access Token belonging to Aqua Security's aqua-bot service account.

What followed was a multi-phase supply chain attack that compromised Trivy's binary releases, GitHub Actions, Docker Hub images, and ultimately breached Cisco's development environment — stealing source code for unreleased AI products and exposing repositories belonging to Cisco's corporate customers.²

Phase 1: The Initial Compromise¶

On February 28, the stolen PAT was used to take over the Trivy repository — privatizing it, deleting GitHub Releases between v0.27.0 and v0.69.1, and pushing a suspicious artifact to the Trivy VSCode extension.³

Aqua Security discovered the breach, disclosed it, and rotated credentials.

But the rotation was not atomic. Some credentials survived. TeamPCP retained a foothold that wouldn't surface for three weeks.

Phase 2: The Real Attack¶

On March 19, 2026 at approximately 17:43 UTC, TeamPCP used the surviving credentials to launch the primary attack:⁴

• Force-pushed 76 of 77 version tags in aquasecurity/trivy-action to point at malicious commits
• Force-pushed all 7 tags in aquasecurity/setup-trivy to malicious commits
• Published a malicious Trivy binary as v0.69.4 via the compromised release automation
• Pushed malicious workflows to tfsec, traceeshark, and trivy-action repositories

By March 22, compromised Docker Hub images (v0.69.5, v0.69.6) appeared, and a worm-like payload began propagating through npm packages using stolen credentials harvested from CI runners.⁵

The Payload¶

The injected code — TeamPCP's custom "Cloud Stealer" — was surgical:⁶

1. Memory scraping: Read /proc/<pid>/mem from the GitHub Actions Runner.Worker process, searching for the pattern {"value":"<secret>","isSecret":true} to extract masked secrets
2. Filesystem sweep: Harvested SSH keys, cloud credentials (AWS, GCP, Azure), Kubernetes tokens, Docker configs, and Git credentials across 50+ sensitive file paths
3. Encryption and exfil: AES-256-CBC with RSA-4096 hybrid encryption, bundled into tpcp.tar.gz, exfiltrated to a typosquatted domain (scan.aquasecurtiy.org — note the misspelling)
4. Persistence: Installed a Python script at ~/.config/systemd/user/sysmon.py polling a C2 server every five minutes

How Cisco Was Breached¶

Cisco used Trivy in its CI/CD pipelines. When their GitHub Actions workflows ran the compromised trivy-action, the credential stealer harvested secrets from their build runners. The attackers then used those stolen credentials to:⁷

• Clone 300+ private GitHub repositories, including source code for Cisco AI Assistant, AI Defense, and unreleased products
• Access repositories belonging to Cisco's corporate customers — banks, BPOs, and US government agencies
• Steal AWS access keys, which were used for unauthorized activity across several Cisco AWS accounts
• Compromise dozens of developer and lab workstations

ShinyHunters, working with TeamPCP, posted extortion demands on March 31 with an April 3 deadline.⁸

The Exposure Window¶

Three hours. That's how long the malicious binary was live. And it was enough.

Why It Mattered¶

Mutable tags are not a security boundary. The entire downstream attack worked because GitHub Actions tags can be force-pushed. A workflow pinned to aquasecurity/[email protected] resolved to whatever commit that tag pointed to at runtime. When TeamPCP rewrote 76 tags, every downstream workflow silently ran attacker code with zero changes to the victim's workflow files.

This is the same class of problem as dependency confusion — the identifier you trust doesn't point where you think it does. The fix is the same too: pin to immutable references. For GitHub Actions, that means commit SHAs, not tags.

# Mutable — tag can be rewritten at any time
- uses: aquasecurity/trivy-action@0.28.0

# Immutable — commit SHA cannot be changed
- uses: aquasecurity/trivy-action@a1b2c3d4e5f6...

Security tools are attack surface. Trivy runs with access to CI/CD secrets because it needs to — scanning images, repos, and configs requires broad read access. That same privileged position makes it the highest-value target in your pipeline. This isn't unique to Trivy. Snyk, Grype, Dependabot, any scanner that runs in your CI with access to secrets has the same structural risk. The tool you trust most is the tool most worth compromising.

Credential rotation must be atomic. Aqua Security detected the first compromise quickly and responded. But incomplete rotation left a foothold that TeamPCP exploited three weeks later. Half-rotated credentials are worse than unrotated ones — they create a false sense of security while the attacker waits.

pull_request_target is a footgun. This GitHub Actions trigger has been documented as dangerous since 2020. It runs workflows with the base repository's secrets but can check out code from a fork. If your workflow does anything with the PR's code — builds it, tests it, diffs it — an attacker's fork can execute arbitrary code with your secrets. It's in the GitHub security docs. It's been the subject of multiple advisories. And it was still sitting in Trivy's workflow, waiting.

Three hours is enough. The malicious binary was live for approximately three hours. The compromised tags were live for twelve. In a world of automated CI/CD pipelines that trigger on every push, three hours of compromise can propagate to thousands of downstream builds. Your incident response plan needs to account for the fact that supply chain attacks move at machine speed, not human speed.

The Broader Pattern¶

This attack combined techniques from SolarWinds (compromise the trusted tool to reach downstream targets), xz utils (patient, multi-phase social engineering of open-source infrastructure), and build pipeline exploitation. It's the convergence this guide has been warning about.

The defenses are structural, not heroic:

• Pin GitHub Actions to commit SHAs, not version tags — this single change would have made the tag-poisoning attack ineffective
• Treat security scanners as privileged workloads — they need access to secrets, so they need the same scrutiny as any other privileged component
• Monitor outbound connections from CI runners — StepSecurity's Harden-Runner detected anomalous connections to the typosquatted domain across 45+ repos during the exposure window⁴
• Rotate credentials atomically — partial rotation is partial security, which is no security
• Audit your GitHub Actions workflows for pull_request_target with checkout of PR code — it's the single most common Actions footgun and it's been documented for six years
• Run trivy-action (or any scanner) in a restricted runner with network egress controls and minimal secret exposure

Timeline¶