How Trivy Was Compromised to Deliver Malware (Again)

Your Security Scanner Was the Weapon. Trivy Compromised Again.

Malicious v0.69.4 binaries with a C2 phone-home shipped via Trivy’s official release automation - three weeks after the first attack. Here’s what happened, what was in the binary, and what your pipeline should do right now.

On March 19, 2026, Trivy - the most widely used open-source vulnerability scanner in DevSecOps pipelines - had its release process compromised for the second time in three weeks. The malicious v0.69.4 release was published via the project’s own aqua-bot automation, reached Homebrew, and triggered normal downstream integrations before maintainers caught it. The tool you trust to find malware was delivering malware.

What Is Trivy and Why Does This Hurt

Trivy is Aqua Security’s open-source vulnerability scanner - the default scanner in thousands of CI/CD pipelines, Kubernetes admission controllers, GitHub Actions workflows, and developer workstations. If you run container security scanning in your organisation, there is a very good chance Trivy is how you do it.

That ubiquity is precisely why this attack matters. A compromised Trivy binary is not a vulnerability in a random utility. It is a backdoor inside the component that is supposed to find backdoors. Pipelines that use Trivy for security gates would have downloaded and executed a binary that phones home to an attacker-controlled domain - while reporting clean scan results to the developer. The tool becomes the weapon.

This is the second time the Trivy repository was compromised. The first incident happened three weeks earlier on February 28, 2026, and was documented in detail by StepSecurity. Understanding both incidents together reveals a deliberate, patient attacker who came back after partial remediation.

The First Compromise - February 28, 2026

On February 28, an autonomous bot called hackerbot-claw exploited a pull_request_target workflow misconfiguration in the aquasecurity/trivy repository. The attack stole a Personal Access Token (PAT) from the workflow environment. With that credential, the attacker:

• Privatised the entire repository temporarily
• Deleted all GitHub Releases between v0.27.0 and v0.69.1
• Pushed a suspicious artifact to the Trivy VSCode extension on the Open VSX marketplace

Aqua Security disclosed this in GitHub discussion #10265 and performed remediation. The community considered the incident closed. It was not.

The Second Compromise - March 19, 2026

Three weeks after the first incident was publicly disclosed and remediated, the attacker returned. This time they didn’t just delete releases - they pushed a malicious release through the project’s own automation and then tried to bury the evidence.

Malicious v0.69.4 Published via aqua-bot

The trivy release automation (aqua-bot) published v0.69.4 to the repository. A v0.70.0 tag was also briefly created. The release binaries contained malicious code that phones home to a typosquatted C2 domain. Because the release came through official project automation, it triggered all normal downstream processes without any manual review.

Homebrew Automatically Picked It Up

Homebrew’s automated formula update bots noticed the new release and bumped the trivy formula to v0.69.4. Any macOS developer or CI runner doing a brew install trivy or brew upgrade trivy during this window would have installed the compromised binary without any warning.

Helm Chart and Docs PRs Opened Automatically

Downstream automation opened a Helm chart version bump PR and documentation updates - all triggered by the legitimate-looking release. This is a textbook supply chain attack: hijack the release pipeline of a trusted project and let its own trusted automation propagate the malicious payload.

Original Incident Discussion #10265 Deleted

The attacker deleted Aqua Security’s original February disclosure thread (discussion #10265). This thread had become the active location for community discussion about the new v0.69.4 compromise. Deleting it was a deliberate attempt to slow down the incident response - users affected by v0.69.4 had nowhere to find information or coordinate.

setup-trivy Version Tags Removed

All version tags on the aquasecurity/setup-trivy GitHub Action were removed except v0.2.6. Tags v0.1.0 through v0.2.5 were gone. Any CI pipeline pinned to a deleted tag now breaks with a cryptic error. Whether this was attacker action or part of maintainer incident response is not fully confirmed - but the impact on CI pipelines was immediate and widespread.

Coordinated Spam Bot Flood

Within minutes of discussion #10420 being opened (asking why #10265 was deleted), a coordinated wave of bot accounts flooded the thread. Two accounts posted taunts at 00:01 UTC. Then at exactly 00:08 UTC, 17 bot accounts simultaneously posted generic praise comments (“this solved my issue”, “worked perfectly for me”) to bury the real discussion thread under noise. This was a deliberate cover-up operation.

IOCs - What to Look For

The following IOCs were shared by community researcher bored-engineer in discussion #10420 before that thread was suppressed. These were recovered from the deleted #10265 discussion. Treat any of these as a confirmed compromise indicator if found in your environment.

Check If You Were Affected

# Check installed trivy version
trivy --version

# If output shows 0.69.4 → you are affected
# Safe versions: 0.69.3 (downgraded) or 0.69.5+ when available

# Check Homebrew installed version
brew info trivy | grep "Installed"

# Check your CI logs for which version was installed
# Look for: "trivy" AND "0.69.4" in build logs from March 19

# Check if you used setup-trivy without a version pin
grep -r "setup-trivy" .github/workflows/ | grep -v "version:"

Network Indicator - Look for C2 Beaconing

# Check DNS query logs for unusual outbound from CI runners / dev machines
# that ran trivy on March 19

# If you have Falco, check for unexpected DNS lookups from trivy process
journalctl -u falco --since "2026-03-19" | grep -i "trivy"

# Check iptables/firewall logs for outbound connections from scanner processes
# around the time trivy v0.69.4 would have run

# If you have EDR/XDR - query for process: trivy spawning network connections
# to domains NOT in: *.github.com, *.aquasec.com, *.ghcr.io

The Spam Bot Flood and Discussion Deletion

What makes this incident stand out beyond the malicious binary is the deliberate, coordinated effort to suppress incident response. The attacker didn’t just push malicious code - they actively tried to prevent affected users from learning about it.

Discussion #10265 Deleted - Active Incident Buried

Aqua Security’s original February incident disclosure (discussion #10265) had become the gathering point for community discussion about the new v0.69.4 compromise. Users were sharing IOCs, timelines, and mitigation steps there in real time. The attacker deleted the entire thread.

As researcher bored-engineer noted in the replacement discussion #10420: "It wasn't just discussion on the previous well-reported compromise - there was active discussion on the new (as of today) compromise of v0.69.4 trivy binaries. Judging by the subsequent spam comments on this issue, it's likely the threat actor deleted the discussion to slow down the response by impacted users/orgs."

17 Spam Bots in a Single Second

The coordinated bot response to discussion #10420 followed a clear two-phase pattern:

The 17 simultaneous comments prove this was not organic. Seventeen separate accounts posting within the same second requires automation. The objective was clear: flood the discussion with noise to push the real IOC-sharing conversation off the first page and slow down organisations trying to assess their exposure.

What Got Hit and What Broke

Homebrew - Emergency Downgrade PR #273304

Homebrew maintainer woodruffw filed emergency pull request #273304 to downgrade the trivy formula from v0.69.4 back to v0.69.3. This was merged promptly. Any macOS user or CI job that ran brew upgrade after the downgrade is back on the safe version. But anyone who installed or upgraded trivy during the malicious window has a compromised binary on their system.

setup-trivy GitHub Action - All Tags Except v0.2.6 Deleted

The aquasecurity/setup-trivy action is how thousands of GitHub Actions workflows install trivy in CI. After the incident, all tags from v0.1.0 through v0.2.5 were removed - leaving only v0.2.6. The timeline from the GitHub Events API:

Any CI pipeline pinned to a tag like aquasecurity/setup-trivy@v0.2.1 through v0.2.5 broke immediately. GitHub Actions reports a confusing “tag not found” error that gives no indication of why. Users reported the breakage in issue #31 on the setup-trivy repository.

Helm Charts and Documentation

Automated PRs for Helm chart version bumps and documentation updates were opened by downstream bots that picked up the malicious v0.69.4 release. These were closed after the tag was deleted. If your organisation has an internal Helm chart mirror or automated dependency update system (Renovate, Dependabot), check whether any PRs referencing trivy v0.69.4 were merged during the window.

How Aqua Security Responded

Once the compromise was identified, the Trivy maintainers responded with the following actions:

• Deleted the malicious v0.69.4 tag from the trivy repository - removing it from the official release list
• Published v0.2.6 of setup-trivy - replacing the compromised action version
• Removed prior setup-trivy tags - preventing further use of potentially compromised action versions
• Commit 1885610 - pushed a fix titled “fix(ci): Use correct checkout pinning” - addressing the CI workflow configuration that enabled the attack
• Homebrew collaborated to downgrade the formula to v0.69.3 via PR #273304

The remediation commit (1885610c) specifically fixes the CI workflow pinning - the actions/checkout step that was likely being used with insufficient pinning, allowing the attacker to substitute actions or workflows. Correct SHA pinning of all GitHub Actions is the primary technical fix applied.

Immediate Actions for Your Team

1. Run trivy --version on every machine, CI runner, and container that uses trivy. If any shows 0.69.4, treat that system as compromised and isolate it.
2. Check all GitHub Actions workflow files for aquasecurity/setup-trivy references. Update any that pin to v0.2.1 - v0.2.5 to v0.2.6
3. Review CI build logs from March 19, 2026 - identify any job that installed or ran trivy during the malicious window.
4. If trivy v0.69.4 ran in your CI pipeline, check for unexpected outbound network connections from those runners to non-Aqua domains. Treat those runners as potentially compromised.
5. Pin the setup-trivy action to a specific commit SHA - not just a tag. Tags can be deleted and recreated; commit SHAs cannot be changed.
6. Audit all other pull_request_target workflows in your repositories. This is the attack class that enabled the original February compromise.
7. Verify trivy binary integrity with checksum before running in pipelines. Add trivy --version output verification as a pipeline step.
8. Subscribe to the aquasecurity/trivy GitHub repository watch for security advisories - so you are notified of future incidents immediately.

Fix Your GitHub Actions Workflow

# ❌ BEFORE - tag pin (tag can be deleted/recreated)
- name: Install Trivy
  uses: aquasecurity/setup-trivy@v0.2.3  # tag deleted!
  with:
    version: latest  # dangerous - installs whatever is current

# ✓ AFTER - SHA pin + explicit safe version
- name: Install Trivy
  uses: aquasecurity/setup-trivy@v0.2.6
  with:
    version: v0.69.3  # explicit safe version, not latest

# Even better - SHA pin the action itself
- name: Install Trivy (SHA-pinned)
  uses: aquasecurity/setup-trivy@<commit-sha-of-v0.2.6>
  with:
    version: v0.69.3

# Verify version after install
- name: Verify Trivy Version
  run: |
    TRIVY_VER=$(trivy --version | grep -oP 'Version: \K[0-9.]+')
    echo "Installed trivy: $TRIVY_VER"
    if [[ "$TRIVY_VER" == "0.69.4" ]]; then
      echo "ERROR: Compromised version detected!"
      exit 1
    fi

Hardening Against Supply Chain Attacks - The Whole Class

The Trivy incident is a specific instance of a broader class of supply chain attacks targeting open-source tooling in CI/CD pipelines. Here is how to reduce your exposure to the whole class.

1. Never Use Latest or Floating Versions in CI

Every tool, action, or image in your CI pipeline should be pinned to an explicit version. latest, main, or unpinned versions make your pipeline a live target for supply chain attacks.

# ❌ Dangerous floating references
uses: actions/checkout@main
image: aquasec/trivy:latest

# ✓ Pinned to immutable SHA
uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683  # v4.2.2
image: aquasec/trivy:0.69.3

2. Audit pull_request_target Workflows

# Find all pull_request_target workflows in your org
grep -r "pull_request_target" .github/workflows/

# Any workflow using pull_request_target that also:
# - checks out PR code (actions/checkout with ref: ${{ github.event.pull_request.head.sha }})
# - has access to secrets
# - runs untrusted code
# ...is a potential PAT theft vector. Refactor immediately.

3. Verify Binary Checksums for Security Tools

# Download trivy with checksum verification
VERSION="0.69.3"
ARCH="Linux-64bit"

curl -sLO "https://github.com/aquasecurity/trivy/releases/download/v${VERSION}/trivy_${VERSION}_${ARCH}.tar.gz"
curl -sLO "https://github.com/aquasecurity/trivy/releases/download/v${VERSION}/trivy_${VERSION}_${ARCH}.tar.gz.sha256"

# Verify checksum BEFORE extracting or running
sha256sum --check trivy_${VERSION}_${ARCH}.tar.gz.sha256

# Only proceed if checksum matches
if [ $? -eq 0 ]; then
    tar -xzf trivy_${VERSION}_${ARCH}.tar.gz
    echo "Trivy ${VERSION} verified and extracted"
else
    echo "CHECKSUM MISMATCH - do not run this binary"
    exit 1
fi

4. Network Egress Control for CI Runners

# Falco rule - alert on unexpected outbound from scanner processes
- rule: Security Scanner Unexpected Outbound
  desc: Security scanner process connecting to unexpected external host
  condition: |
    evt.type = connect
    and proc.name in (trivy, grype, syft, snyk)
    and fd.typechar = 4
    and not fd.sip.name in (
      "*.github.com", "*.aquasec.com",
      "*.ghcr.io", "*.githubusercontent.com",
      "*.nvd.nist.gov"
    )
  output: Scanner unexpected connection (proc=%proc.name dest=%fd.sip.name)
  priority: CRITICAL
  tags: [network, supply_chain, scanner_integrity]

5. Use StepSecurity Harden-Runner

StepSecurity’s Harden-Runner GitHub Action monitors and restricts outbound network traffic from GitHub Actions runners. It would have detected the C2 phone-home from the malicious trivy binary in real time. Add it as the first step in every workflow:

steps:
  - name: Harden Runner
    uses: step-security/harden-runner@<sha>
    with:
      egress-policy: audit  # start with audit, move to block after baselining
      allowed-endpoints: |
        github.com:443
        ghcr.io:443
        aquasec.com:443

What This Means for DevSecOps

The Trivy supply chain attack is a landmark incident for the DevSecOps community - not because Trivy is uniquely insecure, but because it demonstrates something uncomfortable: security tools are high-value targets precisely because they are trusted. We give our scanners network access, we run them in privileged CI environments, we pipe their output into decision systems. An attacker who controls your scanner controls your security posture.

The second compromise, coming three weeks after a disclosed and “remediated” first incident, shows that the attacker had deeper persistence than the initial response addressed. Rotating secrets after a PAT theft is not enough if the attacker has already established additional backdoors or has maintained access through a compromised bot account.

The coordinated spam bot operation is equally significant. This is not a disorganised opportunistic actor. The capability to spin up 17 coordinated GitHub accounts that post simultaneously within one second, combined with the ability to delete discussions on a popular open-source project, indicates a well-resourced, persistent threat actor.

Trust Nothing. Verify Everything. Pin Everything.

If your security tooling isn’t pinned to an immutable reference, isn’t checksum-verified, and doesn’t have egress monitoring - you’re one supply chain compromise away from your scanner becoming the attacker’s pivot point.