Skip to content

Trivy ecosystem supply chain was briefly compromised

Critical severity GitHub Reviewed Published Mar 21, 2026 in aquasecurity/trivy • Updated Mar 24, 2026

Package

actions aquasecurity/setup-trivy (GitHub Actions)

Affected versions

< 0.2.6

Patched versions

0.2.6
actions aquasecurity/trivy-action (GitHub Actions)
< 0.35.0
0.35.0
gomod github.com/aquasecurity/trivy (Go)
= 0.69.4
None

Description

Summary

On March 19, 2026, a threat actor used compromised credentials to publish a malicious Trivy v0.69.4 release, force-push 76 of 77 version tags in aquasecurity/trivy-action to credential-stealing malware, and replace all 7 tags in aquasecurity/setup-trivy with malicious commits.

On March 22, 2026, a threat actor used compromised credentials to publish a malicious Trivy v0.69.5 and v0.69.6 DockerHub images.

Exposure Window

Component Start (UTC) End (UTC) Duration
trivy v0.69.4 2026-03-19 18:22 1 2026-03-19 ~21:42 ~3 hours
trivy-action 2026-03-19 ~17:43 2 2026-03-20 ~05:40 ~12 hours
setup-trivy 2026-03-19 ~17:43 2 2026-03-19 ~21:44 ~4 hours
dockerhub trivy images v0.69.5 and v0.69.6 2026-03-22 15:43 2026-03-22 ~01:40 ~10 hours

Affected Components

Note that all malicious components, artifacts, commits, etc have been removed from all sources and destinations (yet they may linger in intermediary caches). Use this information to understand if you have been exposed to the malicious artifacts during the exposure window.

trivy binary and image

Users are affected if they utilized:

  1. trivy binaries version v0.69.4 (or latest during the exposure window) distributed via GitHub, Deb, RPM.
  2. trivy container images v0.69.4 (or latest during the exposure window) distributed via GHCR, ECR public, Docker Hub.
  3. trivy container images v0.69.5 and v0.69.6 (or latest during the exposure window) distributed via Docker Hub.

Users are not affected if they utilized:

  1. trivy (binary or image) version v0.69.3 or earlier.
    1. v0.69.3 is protected by GitHub's immutable releases feature (enabled March 3, before v0.69.3 was published).
    2. v0.69.2 predates immutable releases enablement but integrity can be verified via sigstore signatures (see "How to Verify" section below).
  2. trivy images referenced by digest.
  3. trivy binaries built from source.
    1. The malicious code was not committed to Trivy's main branch. It was fetched and built on the ephemeral runner, and also committed to a v0.70.0 branch but no release or git tag was ever pushed.
  4. homebrew from official formula (brew install trivy)
    1. The official homebrew formula is building trivy directly from source.
    2. There's an additional custom trivy tap which was compromised as part of the v0.69.4 release, but that tap requires special installation and is not even mentioned in the trivy documentation.

aquasecurity/trivy-action GitHub Action

Users are affected if they utilized:

  1. Any tags prior except 0.35.0 (0.0.1 – 0.34.2) to reference the action.
  2. the action's version: latest parameter explicitly (not the default) during the trivy binary exposure window.
  3. SHA pinning to a commit prior to 2025-04-09.
    1. trivy-action started pinning setup-go with pull request trivy-action#456. If you pinned trivy-action to a commit prior to that PR (merged 2025-04-09), then you would get a safe trivy-action but it would get a malicious setup-trivy, if invoked during the setup-trivy exposure window.

Users are not affected if they utilized:

  1. 0.35.0 tag
    1. 0.35.0 is protected by GitHub's immutable releases feature (enabled March 4, before 0.35.0 was published) and was not affected by the tag hijacking attack.
  2. SHA pinning to a safe commit commit after 2025-04-09.

aquasecurity/setup-trivy GitHub Action

Users are affected if they utilized:

  1. Any version without pinning.

Users are not affected if they utilized:

  1. SHA pinning to a safe commit.

Attack Details

Root Cause

This incident is a continuation of the supply chain attack that began in late February 2026. Following the initial disclosure on March 1, credential rotation was performed but was not atomic (not all credentials were revoked simultaneously). The attacker could have use a valid token to exfiltrate newly rotated secrets during the rotation window (which lasted a few days). This could have allowed the attacker to retain access and execute the March 19 attack.

Trivy v0.69.4 binary and container images

The attacker created a malicious release by:

  1. Pushing a commit (1885610c) that swapped the actions/checkout reference to an imposter commit (70379aad) containing a composite action that downloaded malicious Go source files from a typosquatted domain
  2. Adding --skip=validate to goreleaser to bypass binary validation
  3. Tagging this commit as v0.69.4, triggering the release pipeline

The compromised release was distributed across Trivy's regular distribution channels channels: GHCR, ECR Public, Docker Hub (both 0.69.4 and latest tags), deb/rpm packages, and get.trivy.dev.

The attacker attempted to release a v0.70.0 malicious release but that was stopped prematurely.

trivy-action tag hijacking

The attacker force-pushed 76 of 77 version tags to malicious commits that injected an infostealer into entrypoint.sh. The malicious code executes before the legitimate Trivy scan and does the following:

  1. Dumps Runner.Worker process memory via /proc/<pid>/mem to extract secrets. Sweeps 50+ filesystem paths for SSH keys, AWS/GCP/Azure credentials, Kubernetes tokens, Docker configs, .env files, database credentials, and cryptocurrency wallets.
  2. Encrypts collected data using AES-256-CBC with RSA-4096 hybrid encryption.
  3. Transmits to attacker-controlled infrastructure. If exfiltration fails and INPUT_GITHUB_PAT is set, creates a public tpcp-docs repository on the victim's GitHub account and uploads stolen data as a release asset.

setup-trivy release replacement

All 7 existing tags (v0.2.0 – v0.2.6) were force-pushed to malicious commits. The malicious action.yaml contained the same infostealer as trivy-action, injected as a "Setup environment" step that executes before the legitimate Trivy installation.
We have removed all malicious releases within ~4 hours and re-created v0.2.6 with safe content. Tags v0.2.0 – v0.2.5 were not restored.

Trivy v0.69.5 and v0.69.6 docker image published.

The attacker created aquasec/trivy:0.69.5 and aquasec/trivy:0.69.6 with the same C2 domain as the v0.69.4 payload, and pushed them directly to Docker Hub using separately-compromised Docker Hub credentials (not via GitHub). No corresponding GitHub tags or releases existed.
We have removed all tags related to 0.69.5 and 0.69.6 and restored the latest tag to the safe 0.69.3 tag.

Recommended Actions

Update to Known-Safe Versions

Component Safe Version
Trivy binary v0.69.2, v0.69.3
trivy-action v0.35.0
setup-trivy v0.2.6

Regarding trivy-action: The original tags (0.0.1 – 0.34.2) were deleted during remediation. Because the attacker's force-push caused these tags to be treated as immutable releases by GitHub, they cannot be re-created with the same names. New tags have been published with a v prefix (v0.0.1 – v0.34.2) pointing to the original legitimate commits. Three tags: v0.0.10, v0.34.1, and v0.34.2 have not yet been restored. If you need to reference a version older than 0.35.0, use the v-prefixed tag (e.g., aquasecurity/trivy-action@v0.34.0 instead of @0.34.0).

Rotate All Potentially Exposed Secrets

Based on information shared above, if there is any possibility that a compromised version ran in a project's environment, all secrets accessible to affected pipelines must be treated as exposed and rotated immediately.

Audit Trivy Versions

Check whether a project's organization pulled or executed Trivy v0.69.4 from any source. Remove any affected artifacts immediately.

Audit GitHub Action References

Review all workflows using aquasecurity/trivy-action or aquasecurity/setup-trivy. Check workflow run logs from March 19–20, 2026 for signs of compromise.

Search for Exfiltration Artifacts

Look for repositories named tpcp-docs in project's GitHub organization. The presence of such a repository may indicate that the fallback exfiltration mechanism was triggered and secrets were successfully stolen.

Pin GitHub Actions to Full SHA Hashes

Pin GitHub Actions to full, immutable commit SHA hashes, don't use mutable version tags. As described here: https://docs.github.com/en/actions/reference/security/secure-use#using-third-party-actions

How to Verify Existing Installations

Binary verification

# Download binary and sigstore bundle
curl -sLO "https://github.com/aquasecurity/trivy/releases/download/v0.69.2/trivy_0.69.2_Linux-64bit.tar.gz"
curl -sLO "https://github.com/aquasecurity/trivy/releases/download/v0.69.2/trivy_0.69.2_Linux-64bit.tar.gz.sigstore.json"

# Verify signature
$ cosign verify-blob \
  --certificate-identity-regexp 'https://github\.com/aquasecurity/' \
  --certificate-oidc-issuer 'https://token.actions.githubusercontent.com' \
  --bundle trivy_0.69.2_Linux-64bit.tar.gz.sigstore.json \
  trivy_0.69.2_Linux-64bit.tar.gz
Verified OK

# Check signing timestamp
$ date -u -d @$(jq -r '.verificationMaterial.tlogEntries[].integratedTime' trivy_0.69.2_Linux-64bit.tar.gz.sigstore.json)
Sat Mar  1 19:11:02 UTC 2026
# ✅ Signed on Mar 1, before the attack on Mar 19

Container image verification

# Verify signature and get image digest
$ cosign verify \
  --certificate-identity-regexp 'https://github\.com/aquasecurity/' \
  --certificate-oidc-issuer 'https://token.actions.githubusercontent.com' \
  --new-bundle-format \
  ghcr.io/aquasecurity/trivy:0.69.2
Verification for ghcr.io/aquasecurity/trivy:0.69.2 --
The following checks were performed on each of these signatures:
  - The cosign claims were validated
  - Existence of the claims in the transparency log was verified offline
  - The code-signing certificate was verified using trusted certificate authority certificates

# Get digest and check all signing timestamps via Rekor
$ DIGEST=$(cosign verify \
  --certificate-identity-regexp 'https://github\.com/aquasecurity/' \
  --certificate-oidc-issuer 'https://token.actions.githubusercontent.com' \
  --new-bundle-format -o json ghcr.io/aquasecurity/trivy:0.69.2 2>/dev/null | \
  jq -r '.[0].critical.image."docker-manifest-digest"')

$ rekor-cli search --sha "$DIGEST" | grep -v 'Found' | while read uuid; do
    rekor-cli get --uuid "$uuid" | grep IntegratedTime
  done
IntegratedTime: 2026-03-01T19:13:52Z
IntegratedTime: 2026-03-01T19:13:47Z
IntegratedTime: 2026-03-01T19:13:57Z
IntegratedTime: 2026-03-01T19:13:54Z
IntegratedTime: 2026-03-01T19:13:46Z
IntegratedTime: 2026-03-01T19:13:37Z
# ✅ All signed on Mar 1, before the attack on Mar 19

Resources

References

Footnotes

  1. Time when v0.69.4 release artifacts became publicly available. The malicious tag was pushed at ~17:43 UTC, triggering the release pipeline. ↩

  2. Earliest suspicious activity observed in our audit log. ↩ ↩2

@itaysk itaysk published to aquasecurity/trivy Mar 21, 2026
Published by the National Vulnerability Database Mar 23, 2026
Published to the GitHub Advisory Database Mar 24, 2026
Reviewed Mar 24, 2026
Last updated Mar 24, 2026

Severity

Critical

CVSS overall score

This score calculates overall vulnerability severity from 0 to 10 and is based on the Common Vulnerability Scoring System (CVSS).
/ 10

CVSS v4 base metrics

Exploitability Metrics
Attack Vector Network
Attack Complexity Low
Attack Requirements None
Privileges Required Low
User interaction None
Vulnerable System Impact Metrics
Confidentiality High
Integrity High
Availability High
Subsequent System Impact Metrics
Confidentiality High
Integrity High
Availability High

CVSS v4 base metrics

Exploitability Metrics
Attack Vector: This metric reflects the context by which vulnerability exploitation is possible. This metric value (and consequently the resulting severity) will be larger the more remote (logically, and physically) an attacker can be in order to exploit the vulnerable system. The assumption is that the number of potential attackers for a vulnerability that could be exploited from across a network is larger than the number of potential attackers that could exploit a vulnerability requiring physical access to a device, and therefore warrants a greater severity.
Attack Complexity: This metric captures measurable actions that must be taken by the attacker to actively evade or circumvent existing built-in security-enhancing conditions in order to obtain a working exploit. These are conditions whose primary purpose is to increase security and/or increase exploit engineering complexity. A vulnerability exploitable without a target-specific variable has a lower complexity than a vulnerability that would require non-trivial customization. This metric is meant to capture security mechanisms utilized by the vulnerable system.
Attack Requirements: This metric captures the prerequisite deployment and execution conditions or variables of the vulnerable system that enable the attack. These differ from security-enhancing techniques/technologies (ref Attack Complexity) as the primary purpose of these conditions is not to explicitly mitigate attacks, but rather, emerge naturally as a consequence of the deployment and execution of the vulnerable system.
Privileges Required: This metric describes the level of privileges an attacker must possess prior to successfully exploiting the vulnerability. The method by which the attacker obtains privileged credentials prior to the attack (e.g., free trial accounts), is outside the scope of this metric. Generally, self-service provisioned accounts do not constitute a privilege requirement if the attacker can grant themselves privileges as part of the attack.
User interaction: This metric captures the requirement for a human user, other than the attacker, to participate in the successful compromise of the vulnerable system. This metric determines whether the vulnerability can be exploited solely at the will of the attacker, or whether a separate user (or user-initiated process) must participate in some manner.
Vulnerable System Impact Metrics
Confidentiality: This metric measures the impact to the confidentiality of the information managed by the VULNERABLE SYSTEM due to a successfully exploited vulnerability. Confidentiality refers to limiting information access and disclosure to only authorized users, as well as preventing access by, or disclosure to, unauthorized ones.
Integrity: This metric measures the impact to integrity of a successfully exploited vulnerability. Integrity refers to the trustworthiness and veracity of information. Integrity of the VULNERABLE SYSTEM is impacted when an attacker makes unauthorized modification of system data. Integrity is also impacted when a system user can repudiate critical actions taken in the context of the system (e.g. due to insufficient logging).
Availability: This metric measures the impact to the availability of the VULNERABLE SYSTEM resulting from a successfully exploited vulnerability. While the Confidentiality and Integrity impact metrics apply to the loss of confidentiality or integrity of data (e.g., information, files) used by the system, this metric refers to the loss of availability of the impacted system itself, such as a networked service (e.g., web, database, email). Since availability refers to the accessibility of information resources, attacks that consume network bandwidth, processor cycles, or disk space all impact the availability of a system.
Subsequent System Impact Metrics
Confidentiality: This metric measures the impact to the confidentiality of the information managed by the SUBSEQUENT SYSTEM due to a successfully exploited vulnerability. Confidentiality refers to limiting information access and disclosure to only authorized users, as well as preventing access by, or disclosure to, unauthorized ones.
Integrity: This metric measures the impact to integrity of a successfully exploited vulnerability. Integrity refers to the trustworthiness and veracity of information. Integrity of the SUBSEQUENT SYSTEM is impacted when an attacker makes unauthorized modification of system data. Integrity is also impacted when a system user can repudiate critical actions taken in the context of the system (e.g. due to insufficient logging).
Availability: This metric measures the impact to the availability of the SUBSEQUENT SYSTEM resulting from a successfully exploited vulnerability. While the Confidentiality and Integrity impact metrics apply to the loss of confidentiality or integrity of data (e.g., information, files) used by the system, this metric refers to the loss of availability of the impacted system itself, such as a networked service (e.g., web, database, email). Since availability refers to the accessibility of information resources, attacks that consume network bandwidth, processor cycles, or disk space all impact the availability of a system.
CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H

EPSS score

Exploit Prediction Scoring System (EPSS)

This score estimates the probability of this vulnerability being exploited within the next 30 days. Data provided by FIRST.
(13th percentile)

Weaknesses

Embedded Malicious Code

The product contains code that appears to be malicious in nature. Learn more on MITRE.

CVE ID

CVE-2026-33634

GHSA ID

GHSA-69fq-xp46-6x23

Source code

Loading Checking history
See something to contribute? Suggest improvements for this vulnerability.