Trivy supply-chain compromise: what happened, what it means, and who is affected

From March 19-20, 2026, the Trivy ecosystem experienced a serious supply-chain security incident affecting multiple distribution channels used by many organizations for CI/CD and developer workflows. Public reporting indicates both a malicious Trivy release (v0.69.4) and a broader compromise of Trivy-related GitHub Actions via tag poisoning, where attackers force-moved version tags to point at malicious commits.

The good news for Echo customers:

Echo’s platform and scanning factory are not affected, and Echo has not served any compromised Trivy image through the Echo image store. We also took the opportunity to re-validate the specific ways we consume Trivy to ensure we are protected against the exact failure mode this incident exploited.

This post explains what happened, what to check in your environment, and the concrete steps we recommend if you use Trivy.

An overview of the Trivy security supply-chain compromise

• What happened:
  
  • Attackers compromised parts of the Trivy supply chain, including a malicious Trivy release (v0.69.4) and compromised Trivy GitHub Actions where many version tags were force-updated to malicious commits.
  • The aquasecurity/setup-trivy GitHub Action, used in CI pipelines to install trivy, was also compromised. All version tags have been removed except v0.2.6, and the IOC aquasecurity/setup-trivy@8afa9b9 points to a commit containing a comprehensive credential stealer injected into action.yaml.
  • If your CI referenced aquasecurity/trivy-action by tag, the tag may have been silently redirected to malicious code that runs before the scan (potentially exposing CI secrets).
• Why it’s dangerous: It runs inside your CI/CD pipeline with full access to secrets. GitHub Actions runners expose environment variables, tokens, SSH keys, cloud credentials, and API keys. Any secret available to your workflow — AWS keys, Docker registry creds, GitHub tokens, Kubernetes configs — was potentially exfiltrated to the attacker.
• What you should do: If you’re using Echo’s Trivy image, you’re safe. If not, you should check local installs for v0.69.4, check that you didn’t use Trivy docker image for version v0.69.4 / latest in this time frame, audit GitHub Actions usage for tag-based references, and rotate secrets if compromised workflows ran.

Breaking down how Trivy was attacked

Two related pieces of reporting are most relevant for defenders:

1) Malicious Trivy release v0.69.4

StepSecurity reports that a compromised release (v0.69.4) was published to the Trivy repository and briefly propagated downstream (including Homebrew) before being rolled back. Trivy maintainers deleted the v0.69.4 tag, and Homebrew downgraded to v0.69.3.

2) GitHub Actions tag poisoning (aquasecurity/trivy-action and aquasecurity/setup-trivy)

Socket reports a broader compromise affecting the Trivy GitHub Action (aquasecurity/trivy-action), where attackers force-pushed a large number of version tags to point at malicious commits. The key nuance is that your workflow may appear “pinned” (e.g., @0.34.2) but still pull attacker-controlled code because the tag reference moved.

StepSecurity also reports compromise evidence for aquasecurity/setup-trivy (an action used to install Trivy), with tags deleted during response, and identifies a credential-stealing payload and exfiltration patterns.

Why is this incident especially risky?

A classic supply-chain failure mode is “malicious latest”, but this incident goes further: it demonstrates why “pinned to a tag” is not the same as “pinned.”

A Git tag is a pointer to a commit. If an attacker can force-move that pointer, then a workflow referencing aquasecurity/trivy-action@0.33.0 may suddenly execute a different commit than it did yesterday, even though your workflow file did not change.[2]

Public reporting describes payload behavior consistent with a secrets/credentials theft attempt, including exfiltration to a typosquatted domain scan.aquasecurtiy.org (note the misspelling).

Echo’s Trivy assessment (what we verified)

Echo uses Trivy as part of our broader scanning and image security workflows, so we immediately conducted internal checks, which validated that Echo’s scanning factory and platform were not affected. In particular:

• We avoid relying on mutable references (like tags) for third partycritical CI supply chain components.
• Where Trivy is consumed in automation, we prefer immutable pinning (for example, digest-based pinning for container images, and immutable references for action code).
• We verified the Trivy image available in the Echo image store was not compromised, so we did not, in fact, publish a compromised artifact to customers.

This is exactly the kind of incident Echo is built to protect against: upstream compromise can happen even in widely-trusted tools, and consumers need guardrails that assume “upstream can lie.”

What Trivy users should do right now

1. Check local developer machines (CLI installs)

1. Run trivy --version
2. If you use Homebrew, runbrew info trivy

If you have Trivy v0.69.4, treat that machine as potentially affected and proceed to the “If you are affected” section below.

2. Check CI/CD usage (GitHub Actions)

Search your repos for:

• aquasecurity/trivy-action@
• aquasecurity/setup-trivy@

If you reference these actions by tag, consider it high risk during the incident window described in public reporting. Socket’s analysis suggests tag references were widely poisoned, which means “we pinned to @0.xx.y” may not have protected you.

If you are affected: immediate steps

If your environment ran a compromised Trivy Action tag, or you installed the compromised Trivy release, assume a cautious posture.

1) Rotate secrets for any affected CI workflows

Public reporting recommends treating impacted workflow runs as fully compromised, and rotating any credentials those workflows could access (cloud credentials, registry tokens, deploy keys, API keys, and any repo/org secrets used by the workflow).

2) Contain and clean affected endpoints (if v0.69.4 was installed)

• Remove the affected install.
• Reinstall a known-good version (for example, Homebrew downgraded to v0.69.3).[1]
• Follow your internal incident response process for workstation hygiene if you have it (EDR scan, credential review, etc.).

3) Investigate for indicators called out publicly

Reporting includes the typosquatted domain and other IOCs; incorporate them into your logs review as appropriate.

Key takeaways

Even if your checks look clean, this incident is a good forcing function to harden your posture:

• Prefer pinning GitHub Actions to commit SHAs, not tags.
• Prefer container image digests over tags for any security-critical tooling.
• Reduce CI secret exposure by scoping credentials tightly (least privilege, minimal lifespan, environment separation).
• Add monitoring to detect unexpected outbound connections from CI runners.

Additionally, this incident is a reminder that security failures often happen at the seams (a trustworthy repo, a familiar tag, a workflow that “hasn’t changed in months, or a compromise that rewires the reference behind the scenes)

At Echo, we will continue monitoring upstream updates and will share additional guidance if the picture changes. If you are a customer and want help evaluating your organization’s exposure (CI usage, endpoints, and mitigation steps), reach out through your usual Echo support channel.