github.com/aquasecurity/trivy known bugs

On March 19, 2026, a threat actor used compromised credentials to publish a malicious Trivy v0.69.4 release.

A malicious registry can cause Trivy to leak credentials for legitimate registries such as AWS Elastic Container Registry (ECR), Google Cloud Artifact/Container Registry, or Azure Container Registry (ACR) if the registry is scanned from directly using Trivy. These tokens can then be used to push/pull images from those registries to which the identity/user running Trivy has access. This vulnerability only applies when scanning container images directly from a registry. If you use Docker, containerd or other runtime to pull images locally and scan them with Trivy, you are not affected. To enforce this behavior, you can use the --image-src flag to select which sources you trust.

## Impact If a malicious actor is able to trigger Trivy to scan container images from a crafted malicious registry, it could result in the leakage of credentials for legitimate registries such as AWS Elastic Container Registry (ECR), Google Cloud Artifact/Container Registry, or Azure Container Registry (ACR). These tokens can then be used to push/pull images from those registries to which the identity/user running Trivy has access. Taking AWS as an example, the leakage only occurs when Trivy is able to transparently obtain registry credentials from the default [credential provider chain](https://aws.github.io/aws-sdk-go-v2/docs/configuring-sdk/#specifying-credentials). You are affected if Trivy is executed in any of the following situations: - The environment variables contain static AWS credentials (AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, AWS_SESSION_TOKEN) that have access to ECR. - Within a Pod running on an EKS cluster that has been assigned a role with access to ECR using an [IAM Roles for Service Accounts](https://docs.aws.amazon.com/eks/latest/userguide/iam-roles-for-service-accounts.html) (IRSA) annotation. - etc. You are not affected if the default credential provider chain is unable to obtain valid credentials. The same applies to GCP and Azure. ## Workarounds If you are using Trivy v0.51.2 or later, you are not affected. If you are using Trivy v0.51.1 or prior, you should ensure you only scan images from trusted registries. This vulnerability only applies when scanning container images directly from a registry. If you use Docker, containerd or other runtime to pull images locally and scan them with Trivy, you are not affected. To enforce this behavior, you can use the `--image-src` flag to select which sources you trust.

## 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-23 ~01:40 | ~10 hours | [^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. ## 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 You are affected if you used: 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. You are not affected if you used: 1. trivy (binary or image) version v0.69.3 or earlier. 1. v0.69.3 is protected by GitHub's [immutable releases](https://docs.github.com/en/repositories/releasing-projects-on-github/managing-releases-in-a-repository#creating-a-release) 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. 4. 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. 5. homebrew from official formula (`brew install trivy`) 1. The [official homebrew formula](https://github.com/Homebrew/homebrew-core/blob/785817ba05ed32eef15490bb105f67bd973aa7c2/Formula/t/trivy.rb) is building trivy directly from source. 2. There's an additional custom [trivy tap](https://github.com/aquasecurity/homebrew-trivy) 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 You are affected if you used: 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](https://github.com/aquasecurity/trivy-action/pull/456#event-17180670975). 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. You are not affected if you used: 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 You are affected if you used: 1. Any version without pinning. You are not affected if you used: 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/[email protected]` instead of `@0.34.0`). ### Rotate All Potentially Exposed Secrets Based on information shared above, if there is any possibility that a