When the Scanner Becomes the Threat: Inside the Trivy Supply Chain Attack

In March 2026, a widely trusted security tool was turned into an attack vector. Trivy, an open-source vulnerability scanner used across CI/CD pipelines, was compromised and used to exfiltrate sensitive credentials from build environments.

This was not a typical supply chain attack involving a malicious dependency or a new package. Instead, attackers manipulated trusted components already in use, allowing malicious code to execute inside existing pipelines without introducing obvious changes. 

The scope and timing of the incident were established by Aqua Security's official incident disclosure, which confirmed the compromise and defined the exposure window, spanning several hours across multiple release channels before remediation.

What Happened

Attackers gained access to Trivy’s release and automation environment and used that access to distribute malicious code through both releases and GitHub Actions. Analysis from Wiz and Socket Security detailed how compromised releases and GitHub Actions version tags were used to execute malicious code inside CI/CD pipelines.

The attack involved multiple coordinated steps:

1. Compromised versions including 0.69.4, 0.69.5 and 0.69.6 were removed from distribution channels. The last known clean release is 0.69.3
2. Malicious container images were also distributed via Docker Hub, extending the impact beyond GitHub Actions into broader CI/CD environments.
3. Existing GitHub Actions version tags were force-updated to point to attacker-controlled commits.
4. CI/CD pipelines continued to run as expected while executing the injected payload.

The use of version tags instead of immutable commit references in the pipelines resulted in the inadvertent fetching and execution of the compromised code.

Why This Attack Is Different

Most supply chain attacks rely on introducing something new into the environment, such as a malicious package or a compromised dependency version. This attack instead modified what teams already trusted and were actively using.

The key distinction is that no upgrade or change was required on the user side. Pipelines continued referencing the same tags, but those tags no longer pointed to the original code.

As a result, there were no clear signals such as version changes, failed builds or new dependencies that would typically trigger investigation.

How the Attack Worked

Initial Access Through CI/CD Token Exposure

The attack is linked to the compromise of a GitHub Personal Access Token (PAT) associated with Trivy’s CI/CD environment. This token provided write access to repositories and allowed attackers to manipulate release artifacts and Git tags. With this level of access, attackers were able to operate within the trusted release pipeline rather than outside of it.

Release Pipeline Manipulation

Attackers embedded malicious code into the legitimate release process and distributed it as an official version. Due to the inherent trust in the release mechanism, this compromised version was indistinguishable from a standard update. Consequently, any workflow utilizing this version executed the payload as part of its normal operations.

GitHub Actions Tag Hijacking

The most impactful part of the attack was the modification of existing GitHub Action tags. Instead of waiting for users to upgrade, attackers repointed existing version tags to malicious commits. Any pipeline referencing those tags automatically began executing attacker-controlled code. This exploited a common assumption in CI/CD workflows that version tags are stable and trustworthy.

Execution Inside CI/CD Pipelines

The malicious payload executed at runtime within CI/CD jobs before the scanning process completed. After execution, the scanner continued to run normally, producing expected results and avoiding detection. 

During execution, the payload:

• Collected environment variables from the CI runtime.
• Extracted cloud credentials across AWS, GCP and Azure.
• Accessed GitHub tokens and other authentication artifacts.
• Scanned the filesystem for additional secrets.
• Exfiltrated collected data to attacker-controlled infrastructure.

The pipeline continued to operate normally, providing no immediate indication of compromise

What Was at Risk

The attack targeted high-value credentials that exist only at runtime and are rarely visible to traditional scanning tools.

These included:

• CI/CD environment variables.
• GitHub tokens and personal access tokens.
• Cloud provider credentials.
• Kubernetes service account tokens.
• Container registry credentials.

These credentials often provide direct access to production systems, making them significantly more impactful than static code-level vulnerabilities.

Why CI/CD Became the Blast Radius

CI/CD pipelines are uniquely positioned as high-value targets because they combine execution, access, and trust.

They typically:

• Execute code automatically as part of build and deployment processes.
• Store and use privileged credentials.
• Have network access to internal and production environments.
• Operate with limited runtime visibility or monitoring.

Once compromised, a CI pipeline becomes an effective mechanism for both data exfiltration and lateral movement.

Attribution and Related Activity

Indicators suggest the attack infrastructure is linked to TeamPCP, a group known for targeting cloud environments and harvesting credentials. This activity may connect to larger supply chain compromises and credential reuse across multiple systems, reflecting a common modern attack pattern of using initial access for lateral expansion.

Analysis suggests the compromised components may enable behaviors beyond credential theft, potentially propagating across environments and impacting containerized workloads like Kubernetes. These evolving capabilities are under investigation.

Why Detection Failed

This attack bypassed traditional detection mechanisms because it operated within trusted execution paths.

Several factors contributed to this:

• Static analysis tools do not inspect runtime behavior within CI pipelines.
• Version-based trust models assume tags are immutable, which is not always the case.
• The scanner continued functioning normally, masking malicious execution.
• There was no visibility into what actually executed during pipeline runtime.

As a result, the attack did not trigger typical alerts or anomalies.

Immediate Actions

Organizations using Trivy or similar CI-integrated tools should take the following steps:

1. Assume that CI/CD secrets may have been exposed during the affected timeframe.
2. Rotate all credentials used within pipelines, including tokens and cloud keys.
3. Audit pipeline execution logs for unusual behavior or unexpected network activity.
4. Identify workflows using trivy-action or related components.
5. Replace version tags with immutable commit SHAs to ensure pipeline execution cannot be altered by tag changes. For example, replace: uses: aquasecurity/trivy-action@v0.69.4 with uses: aquasecurity/trivy-action@<commit-sha>

What This Means for AppSec

This incident underscores a major evolution of the attack surface: security tools and CI/CD pipelines are now primary targets, not just defenses. Consequently, reliance on traditional trust anchors, such as source, version or reputation, is insufficient. Trust must now be grounded in verifiable runtime execution. 

While most security models prioritize validating what should run based on configuration, this attack highlights that the critical security gap lies in confirming whether what actually ran aligned with expectations. Without deep visibility into runtime execution, this verification is impossible, necessitating a decisive move toward security models that are inherently runtime-aware.

Indicators of Compromise

The following indicators have been associated with the compromised Trivy releases and GitHub Actions workflows. Organizations should review CI/CD activity and logs for these signals.

Network Indicators

These domains may appear in outbound requests originating from CI runners during pipeline execution.

File and Binary Indicators

Multiple malicious binaries were distributed across architectures, including:

• Linux: 32-bit, 64-bit, ARM, ARM64, s390x, PPC64LE
• macOS: Intel and ARM
• Windows: 64-bit
  

These binaries were associated with specific SHA-256 hashes identified in compromised releases. Given the volume of indicators, a full list of hashes should be reviewed directly from primary research sources.

Malicious Workflow Activity

References

1. Aqua. March 23, 2026. Update: Ongoing Investigation and Additional Activity. Aqua
2. Aqua Security. March 20, 2026. Trivy Security Incident 2026-03-19 (#10425).GitHub Discussions. 
3. Crowdstrike. March 20, 2026. From Scanner to Stealer: Inside the trivy-action Supply Chain Compromise. CrowdStrike
4. iTnews. March 20, 2026. "CanisterWorm" supply chain malware attacks npm. iTnews
5. Socket. March 2, 2026. Unauthorized AI Agent Execution Code Published to OpenVSX in Aqua Trivy VS Code Extension. Socket
6. Socket. March 20, 2026. Trivy Under Attack Again: Widespread GitHub Actions Tag Compromise Exposes CI/CD Secrets. Socket
7. The Hacker News. March 20, 2026. Trivy Security Scanner GitHub Actions Breached, 75 Tags Hijacked to Steal CI/CD Secrets. The Hacker News
8. The Hacker News. March 23, 2026. Trivy Hack Spreads Infostealer via Docker, Triggers Worm and Kubernetes Wiper. The Hacker News
9. Wiz. March 20, 2026. Trivy Compromised: Everything You Need to Know about the Latest Supply Chain Attack. Wiz