Trivy Compromised a Second Time - Malicious v0.69.4 Release, aquasecurity/setup-trivy, aquasecurity/trivy-action GitHub Actions Compromised

This is an active investigation. We are continuing to monitor the situation and will update this post as new information becomes available.

Community Webinar: Recovering from the Trivy Compromise

We hosted a webinar to help the community assess impact, understand the attack chain, and take recovery steps. We walked through how to check if your CI/CD pipelines were affected, how to identify compromised credentials, and how to protect against similar attacks going forward.

March 20, 2026 · 10:00 AM Pacific Time

Watch recording: https://youtu.be/ksOT0Ldx2P0

‍

On March 19, 2026, trivy — a widely used open source vulnerability scanner maintained by Aqua Security — experienced a second security incident. Three weeks after the hackerbot-claw incident on February 28 that resulted in a repository takeover, a new compromised release (v0.69.4) was published to the trivy repository. The original incident disclosure discussion (#10265) was also deleted during this period, and version tags on the aquasecurity/setup-trivy GitHub Action were removed.

Trivy maintainers deleted the v0.69.4 tag and Homebrew downgraded to v0.69.3. The following is a factual account of what we observed through public GitHub data.

In addition, we found evidence that the aquasecurity/setup-trivy GitHub Action was also compromised. A commit (8afa9b9) — listed as an IOC in the deleted discussion — contains a comprehensive credential stealer injected into action.yaml. All version tags on setup-trivy have been deleted except v0.2.6, which points to a clean commit.

aquasecurity/trivy-action is still compromised at the time of writing.

StepSecurity Harden-Runner, whose community tier is free for public repos and is used by over 12,000 public repositories, detected the compromised trivy-action making outbound connections to the attacker's C2 domain across multiple open source projects. Harden-Runner insights for community tier projects are public by design, you can check the detections yourself (e.g., k8gb summary, network events). We have reported the impact to all affected community tier projects.

What Happened

Background: The Original Compromise (February 28, 2026)

On February 28, an autonomous bot called hackerbot-claw exploited a pull_request_target workflow in aquasecurity/trivy to steal a Personal Access Token (PAT). The stolen credential was used to take over the repository — privatizing it, deleting all GitHub Releases between v0.27.0 and v0.69.1, and pushing a suspicious artifact to the Trivy VSCode extension on the Open VSX marketplace. Aqua Security disclosed the incident in discussion #10265 and remediated the immediate damage.

StepSecurity documented the full campaign in our hackerbot-claw blog post.

The Second Compromise (March 19, 2026)

Three weeks later, the attacker struck again. Based on the GitHub Events API, repository activity, and IOCs shared before the incident discussion was deleted, here is what we have confirmed:

1. Malicious trivy v0.69.4 Published

The trivy release automation (aqua-bot) published v0.69.4 and a v0.70.0 tag was also briefly created. The v0.69.4 binaries contained malicious code that phones home to a typosquat C2 domain. The release triggered normal downstream automation — Homebrew picked it up, a helm chart bump PR was opened, and documentation was deployed.

2. Original Incident Discussion Deleted

Discussion #10265 — Aqua Security's original incident disclosure from the February compromise — was deleted. This discussion contained active conversation about the new v0.69.4 compromise. As user bored-engineer noted:

"To be explicit, 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."

3. Spam Bot Flood

Within minutes of discussion #10420 being opened (asking why the incident discussion was deleted), a wave of spam bot accounts flooded the thread:

• Two accounts posted "sugma and ligma, teampcp owns you" at 00:01 UTC
• At least 17 bot accounts posted generic praise comments ("this solved my issue", "worked perfectly for me") within a single second at 00:08 UTC — a clear coordinated bot attack to bury the real discussion

4. aquasecurity/trivy-action and aquasecurity/setup-trivy GitHub Action Compromised

‍

trivy-action — Still Compromised

StepSecurity team created an issue: https://github.com/aquasecurity/trivy-action/issues/541

The same credential stealer was also injected into aquasecurity/trivy-action. All (except one) tags are modified to point to malicious commits. This commit modifies entrypoint.sh (+105/-2 lines) with the same payload — Runner process environment harvesting, base64-encoded Python credential stealer, RSA encryption, and exfiltration to scan.aquasecurtiy.org. GitHub displays the same warning: "This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository."

aquasecurity/trivy-action is still compromised at the time of writing. If you use this action, stop using it immediately.

‍

aquasecurity/setup-trivy was also compromised

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 (shared by bored-engineer from the deleted discussion) points to a commit containing a comprehensive credential stealer injected into action.yaml.

The Compromised Commit

GitHub displays a warning on commit 8afa9b9: "This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository." The commit is built on top of the legitimate 3fb12ec (current main HEAD) and uses the same commit message — "Pin Trivy install script checkout to a specific commit (#28)" — as a disguise. The legitimate commit has 4 additions; the malicious one has 117 additions and 12 deletions.

The injected code in the "Setup environment" step:

• Harvests Runner process environment variables — scans /proc/*/environ for SSH and environment-related secrets
• Reads GitHub Actions Runner worker memory (on Linux) — decodes a base64 Python script that locates the Runner.Worker process and reads its memory via /proc/<pid>/mem to extract secrets marked isSecret: true
• Runs a comprehensive credential stealer (on other platforms) targeting SSH keys, Git credentials, AWS/GCP/Azure credentials, Kubernetes secrets, Docker configs, database credentials, Terraform state, crypto wallets (Solana, Bitcoin, Ethereum, Cardano), SSL private keys, shell histories, and more
• Encrypts all collected data with a hardcoded RSA-4096 public key using hybrid encryption (AES-256-CBC + RSA-OAEP)
• Exfiltrates to scan.aquasecurtiy.org — the same typosquat C2 domain listed as an IOC for the trivy compromise
• Fallback exfiltration — if the C2 is unreachable and a GitHub PAT is available, creates a public repository called tpcp-docs on the victim's GitHub account and uploads the stolen data as a release asset. The name "tpcp" matches the "teampcp owns you" message posted by spam bots in discussion #10420.

Tag Deletions and Incident Response

The setup-trivy events API shows the following incident response activity:

• 21:07 UTC — nikpivkin (trivy maintainer) deletes v0.2.5 tag
• 21:34 UTC — itaysk adds simar7 as a collaborator
• 21:43 UTC — simar7 publishes clean v0.2.6 release pointing to 3fb12ec

The deletion of the other tags (v0.2.0–v0.2.4) is not visible in the events API. The compromised commit likely originated from a fork — as GitHub's warning suggests — and the version tags were then moved to reference it. This is a known attack technique with GitHub Actions: tags can reference any commit in the repository's object store, including commits pushed via forks, so moving a tag to a fork commit is sufficient to serve malicious code to all users of that tag. The fact that all version tags were deleted during incident response confirms the tags were pointed to the compromised commit.

Any CI pipeline pinned to a deleted tag is now broken. Users have reported this in issue #31, with a commenter noting: "Looks like all tags/releases other than 0.2.6 are gone."

‍

5. Homebrew Emergency Downgrade

Homebrew maintainer woodruffw filed PR #273304 to emergency downgrade trivy back to v0.69.3, using special labels (CI-version-downgrade, CI-no-bottles) to bypass the normal version audit. The PR was merged, reverting to the existing v0.69.3 bottles.

Harden-Runner Detected Compromised Runs in Community Tier Projects

StepSecurity's Harden-Runner detected outbound connections to the C2 domain scan.aquasecurtiy.org in workflow runs across multiple open source projects using the Harden-Runner community tier. We have reported the impact to all affected community tier projects that were using Harden-Runner, as Harden-Runner was able to detect the malicious outbound connections.

Here is an example from k8gb-io/k8gb, a CNCF project. In this case, Renovate automatically created a PR to update the trivy-action digest, which pointed to the compromised commit. When the workflow ran, Harden-Runner detected the anomalous connection. Since community tier insights are public, you can check this yourself:

• Summary: app.stepsecurity.io/github/k8gb-io/k8gb/actions/runs/23310717748
• Network Events: app.stepsecurity.io/github/k8gb-io/k8gb/actions/runs/23310717748?tab=network-events

How Harden-Runner Detects This

Harden-Runner correlates outbound network calls to each step in a workflow and builds a baseline of expected network destinations over time. When a new destination appears that is not in the baseline, it is flagged as anomalous. In this case, scan.aquasecurtiy.org had never appeared in any previous run of this workflow — making it immediately visible.

Harden-Runner Analysis of the Compromised setup-trivy Commit

We ran the compromised setup-trivy@8afa9b9 commit in a controlled workflow with Harden-Runner in audit mode to observe its runtime behavior. Harden-Runner flagged two detections:

• Summary: app.stepsecurity.io/github/actions-security-demo/compromised-packages/actions/runs/23326425755
• Network Events: app.stepsecurity.io/github/actions-security-demo/compromised-packages/actions/runs/23326425755?tab=network-events
• Process Events: app.stepsecurity.io/github/actions-security-demo/compromised-packages/actions/runs/23326425755?tab=process-events

• Imposter Commit — the action was detected as referencing a commit that does not belong to any branch on the repository
• Runner Worker Memory Read — python3 (PID 2538) was observed reading /proc/2167/mem, the memory of the Runner.Worker process, to extract GitHub Actions secrets

‍

The network events tab confirmed the outbound connections made by the credential stealer:

• scan.aquasecurtiy.org:443 — the typosquat C2 domain receiving the encrypted stolen data
• github.com:443 — API calls (likely the fallback exfil attempting to create the tpcp-docs repo)
• get.trivy.dev:443 — the trivy install script (legitimate action behavior)
• release-assets.githubusercontent.com:443 — downloading trivy binary (legitimate)

Suspicious process detail: python3 reading the Runner.Worker process memory at /proc/2167/mem to extract GitHub Actions secrets.

‍

Evidence from the GitHub Events API

The trivy events API and setup-trivy events API provide a clear record of the incident. Key events from the trivy repo:

• DeleteEvent — aqua-bot deletes v0.70.0 tag at 17:51 UTC
• CreateEvent — github-actions[bot] creates branch ci/helm-chart/bump-trivy-to-0.69.4 at 18:30 UTC
• PullRequestEvent — aqua-bot opens helm chart bump PR at 18:30 UTC
• DiscussionEvent — devinbfergy opens discussion #10420 at 22:13 UTC
• DeleteEvent — knqyf263 deletes v0.69.4 tag at 23:13 UTC

Timeline

March 19, 2026 — ~17:43 UTC

aqua-bot pushes to branch v0.69.4, triggering documentation deployment

March 19, 2026 — 17:51 UTC

aqua-bot deletes v0.70.0 tag

March 19, 2026 — 18:30 UTC

aqua-bot opens PR #10416: "ci(helm): bump Trivy version to 0.69.4 for Trivy Helm Chart 0.21.4"

‍

March 19, 2026 — 21:07 UTC

nikpivkin deletes v0.2.5 tag on aquasecurity/setup-trivy (compromised tag removed)

March 19, 2026 — 21:34 UTC

itaysk adds simar7 as collaborator on setup-trivy (incident response)

March 19, 2026 — 21:43 UTC

simar7 publishes clean setup-trivy@v0.2.6

March 19, 2026 — 21:50 UTC

Helm chart bump PR #10416 closed (not merged)

March 19, 2026 — 22:13 UTC

devinbfergy opens discussion #10420 asking why the incident discussion was deleted

March 19, 2026 — 23:05 UTC

Homebrew maintainer files emergency downgrade PR to revert trivy to v0.69.3

March 19, 2026 — 23:13 UTC

Trivy maintainer knqyf263 deletes v0.69.4 tag

March 19, 2026 — 23:56 UTC

bored-engineer confirms v0.69.4 binaries were compromised and shares IOCs from deleted discussion

March 20, 2026 — 00:01 UTC

Spam bots flood discussion #10420

Indicators of Compromise

The following IOCs were shared by bored-engineer in discussion #10420, copied from the now-deleted discussion #10265 before it was removed:

• C2 domain: scan[.]aquasecurtiy[.]org — note the typo (securtiy vs security), a typosquat of Aqua Security's domain. Resolves to 45.148.10.212 (TECHOFF SRV LIMITED, Amsterdam, NL)
• Referenced GitHub Action: aquasecurity/setup-trivy@8afa9b9 — this is a legitimate commit; workflows using it would have installed the compromised v0.69.4 binary
• Referenced checkout ref: actions/checkout@70379aa — a legitimate actions/checkout commit
• Compromised trivy version: v0.69.4 (tag deleted by maintainer)
• Deleted setup-trivy tags: all tags except v0.2.6 have been removed; it is unclear whether this was done by the attacker or as part of incident response

For the Community: Recovery Steps

If you use aquasecurity/trivy-action, aquasecurity/setup-trivy, or the trivy binary directly in your workflows, here are the steps to recover:

1. Find impacted workflows and workflow runs — Identify which workflows reference the compromised actions and which runs executed them. We have open sourced trivy-compromise-scanner to help with this: https://github.com/step-security/trivy-compromise-scanner. The tool scans your organization for workflow runs that used compromised commit SHAs (full list: https://github.com/step-security/trivy-compromise-scanner/blob/main/internal/scanner/patterns.go).
   
   Important: The scanner detects usage of compromised GitHub Action commits. However, if your workflows use the trivy binary directly (e.g., downloading and running trivy without using the GitHub Actions), this tool will not detect it. The trivy binary (v0.69.4) was also compromised, and we have observed cases where it was used directly in workflows. In this case, check your workflow logs and network logs for connections to scan.aquasecurtiy.org or 45.148.10.212.
2. Find the secrets that need to be rotated — For each impacted workflow run, review what secrets the workflow had access to. This includes any secrets referenced via ${{ secrets.* }} and the GITHUB_TOKEN. If secrets: inherit was used, our analysis shows that only secrets actually referenced in the reusable workflow are loaded into Runner.Worker memory — so you need to rotate the secrets used in the reusable workflow, not all org/repo secrets. See this workflow run for evidence of which secrets are extracted from memory.
3. Rotate all affected secrets — Rotate every credential that was accessible to the impacted workflow runs. This includes GitHub tokens, cloud provider credentials (AWS, GCP, Azure), Docker registry tokens, and any other secrets.

Feel free to start a free-trial to help with you this investigation and recovery: https://www.stepsecurity.io/start-free

For StepSecurity Enterprise Customers

Threat Center Alert

StepSecurity has published a threat intel alert for this incident in the Threat Center. The alert includes all relevant links to check if your organization is affected — including links to check which workflows use the compromised actions, Harden-Runner detections for imposter commits and Runner worker memory reads, and org baseline checks for the C2 domain.

Find Where These Actions Are Used

Use the GitHub Actions In Use dashboard to see all GitHub Actions used across your organization and which repositories use each action. Search for aquasecurity/trivy-action and aquasecurity/setup-trivy to identify every repository and workflow that needs to be reviewed.

Compromised Actions Policy

StepSecurity has added both aquasecurity/setup-trivy and aquasecurity/trivy-action to the compromised actions list. If you have the Compromised Actions workflow run policy enabled, any workflow that uses these actions will be automatically cancelled by @stepsecurity-app[bot] before the compromised code can execute.

Check Your Org Baseline for the C2 Domain

The Harden-Runner org baseline shows whether any workflow in your organization has made outbound connections to the C2 domain scan.aquasecurity.org. If this domain appears in your baseline, the compromised action executed in your environment.

Harden-Runner Block Policy

Harden-Runner supports a block policy that restricts outbound network traffic to only allowed endpoints. If this was configured, the outbound connection to scan.aquasecurtiy.org would have been blocked before any data was exfiltrated. Allowed endpoints can be managed centrally using the Policy Store.

Lockdown Mode

Harden-Runner also supports Lockdown Mode, which blocks the job from running when suspicious process events are detected — such as a process reading Runner.Worker memory. In this attack, the credential stealer reads /proc/<pid>/mem of the Runner.Worker process to extract secrets. With Lockdown Mode enabled, this suspicious process event would have been detected and the job would have been blocked from continuing, preventing both the memory read and the subsequent exfiltration.

Imposter Commit Detections

The Imposter Commit detection flags all workflow runs that used a GitHub Action referencing a commit that does not belong to any branch on the action's repository. The Runner Worker Memory Read detection flags processes that read the Runner.Worker process memory to extract secrets. Both setup-trivy and trivy-action compromised commits trigger these detections.

Harden-Runner Insights for trivy-action

We also ran the compromised trivy-action@0.33.1 with Harden-Runner. The results mirror the setup-trivy analysis — the same credential stealer, the same C2 domain, the same Runner worker memory read.

Rotate Credentials for Affected Workflow Runs

If any workflow run in your organization executed the compromised trivy-action or setup-trivy, you should assume that all credentials accessible to that workflow have been exfiltrated. This includes GitHub tokens, cloud provider credentials (AWS, GCP, Azure), Docker registry tokens, and any other secrets passed to the workflow. Rotate all credentials that the affected workflow had access to immediately.

Review All Secrets Using the Action Secrets Dashboard

Use the StepSecurity Action Secrets dashboard to review all organization-level and repository-level secrets across your organization. The dashboard shows which repositories have which secrets and how long since they were last rotated — helping you prioritize which credentials to rotate first

Enable Secret Exfiltration Policy

If attackers have stolen credentials, they may attempt to create new workflows that exfiltrate secrets. We recommend enabling the Secret Exfiltration workflow run policy. This policy automatically cancels job runs when a new workflow is added that accesses secrets — a common pattern used by attackers who have compromised repository credentials to exfiltrate secrets via newly created workflow files.

Acknowledgement

We would like to thank bored-engineer for sharing the IOCs from the deleted discussion in discussion #10420, and additional details which enabled our investigation. Their quick action in preserving the IOCs before the discussion was removed was critical to identifying the scope of the compromise.

We also thank the Homebrew team for quickly downgrading trivy to v0.69.3, limiting the exposure for users who install trivy via Homebrew.

References

• Discussion #10420: Why did this discussion about the Trivy incident get removed/closed
• Homebrew PR #273304: trivy: downgrade to 0.69.3
• setup-trivy Issue #31: Unable to resolve action aquasecurity/setup-trivy@v0.2.0
• StepSecurity Blog: hackerbot-claw — AI-Powered GitHub Actions Attack Campaign (original incident)

‍