Security teams spend enormous energy scanning their infrastructure for vulnerabilities. But almost nobody asks a harder question: what happens when the scanner itself becomes the vulnerability?

On March 1, 2026, that question stopped being hypothetical.

Key Indicators

KPI Strip: Key incident metrics

What Happened to Trivy

Trivy is one of the most widely deployed open-source vulnerability scanners in the world — embedded in CI/CD pipelines, container registries, and security workflows across thousands of organizations. On February 28, an autonomous AI-powered attack bot called hackerbot-claw exploited a misconfigured GitHub Actions workflow in the Trivy repository using a classic pull_request_target attack pattern. The bot triggered a workflow with elevated repository permissions, exfiltrated a Personal Access Token (PAT), and used it to execute a full repository takeover.

The damage, confirmed by Aqua Security maintainers, was severe:

• The repository was renamed and made private, replaced with an empty repo
• All GitHub Releases between v0.27.0 and v0.69.1 were deleted — along with associated release assets and discussions
• A malicious artifact was pushed to Trivy’s VS Code extension on the Open VSIX marketplace
• Binary downloads via get.trivy.dev, the install script, and Trivy Action were broken for every pinned version in the deleted range

As StepSecurity documented in their forensic breakdown, the attack began even earlier than the hackerbot PR. A prior, untracked PR (#10252 on Feb 27) triggered CI and leaked the PAT hours before the visible vandalism. The entire attack chain — from initial PAT leak to full repository compromise — spanned less than 24 hours.

Attack Timeline

Attack Timeline: 10-day chain from account creation to full repo compromise

The attack unfolded across 10 days with the most damaging phases compressed into 54 hours.

The pull_request_target Vulnerability Explained

The root cause of the Trivy compromise was a GitHub Actions workflow misconfiguration that has been publicly documented for years — yet remains widespread across open-source repositories. The vulnerable pattern is known as a “Pwn Request.”The pull_request_target trigger runs a workflow in the context of the base repository — meaning it has access to the repository’s secrets and elevated permissions. The critical danger: if the workflow checks out and executes code from a pull request’s head branch, it runs attacker-controlled code with those elevated permissions. An untrusted fork can trigger the base repository’s secrets to be exfiltrated.

Trivy’s vulnerable workflow (apidiff.yaml) had used this trigger since October 2025. On February 27, 2026, an attacker opened PR #10252 — then closed it immediately. The workflow fired anyway, checked out the attacker’s fork code, and exfiltrated a PAT to recv.hackmoltrepeat.com. Within 54 hours, the repository was fully compromised.

‍

The Blind Spot in Traditional Vulnerability Management

The security industry has built sophisticated systems for tracking CVEs assigned to packages. What it has built almost nothing for is tracking the security posture of the tools doing the tracking.

This is a structural gap — and the Trivy incident makes it impossible to ignore.

When Trivy was compromised:

• Customers pinned to affected release versions found their CI/CD pipelines silently broken — no error, no warning, just a missing release asset
• Customers using the VS Code extension from the Open VSIX marketplace were exposed to a potentially malicious artifact pushed under Aqua Security’s legitimate publisher identity
• Customers installing Trivy via the GitHub install script or get.trivy.dev hit a degraded service with no clean fallback path
• None of these customers received an automated alert because there was no CVE to trigger one

The traditional vulnerability management model — scan assets, match against NVD, triage by CVSS — is blind to this entire class of risk. Supply chain compromises don’t arrive as CVE advisories. They arrive as broken pipelines, corrupted release artifacts, and malicious extensions wearing trusted digital identities.

Traditional VM vs Zest: The structural blind spot exposed

Traditional vulnerability management has no signal path for compromised scanner tooling. Zest tracks the security tooling layer as part of the infrastructure model.

Zest’s View: Third-Party Tool Risk Is Infrastructure Risk

At Zest, we track what tools are running inside our customers’ environments — not just the vulnerabilities inside those tools. This distinction matters enormously when a tool like Trivy becomes the attack vector.

When we queried our production data as of March 2, 2026, we found 8 active Zest customers running Trivy in their CI/CD and container scanning workflows, accounting for over 16,000 Trivy scan executions in the past 30 days alone:

Zest Trivy Customer Usage & Attack Exposure Window

Left: Trivy scan volume across Zest customers. Purple = active in 2026. Right: The 54-hour attack phase breakdown — from silent PAT exposure to mass release deletion.

Five of these customers — ran Trivy scans on the exact same day the repository was compromised. Three of them appear to have scans that executed after the PAT theft occurred at 03:47 UTC.

That is not an abstract supply chain risk. That is a concrete, time-stamped question every one of those security teams now has to answer: which version of Trivy was running, how was it installed, and was the installation method affected?

The Third-Party Risk Anatomy of This Incident

What makes the Trivy incident instructive is that it demonstrates all three vectors through which third-party tool compromise propagates into customer environments:

The Three Attack Vectors: How the compromise propagated

All three vectors bypassed traditional CVE-based detection entirely. No CVSS score was assigned. No NVD entry was published.

Are You Affected? Which Trivy Installation Methods Were Compromised

Not all Trivy installation methods were equally impacted. Understanding your exposure requires knowing how Trivy is installed in your environment. Here is a breakdown of what was and was not affected:

GitHub Releases (pinned versions v0.27.0–v0.69.1): AFFECTED — all release assets in this range were deleted. Pipelines pinning to these versions broke silently.

Trivy GitHub Action (aquasecurity/trivy-action): AFFECTED — the action downloads binaries from GitHub Releases. Any version referencing the deleted range fails with exit code 1.

Install script (get.trivy.dev): AFFECTED — the install script pointed to GitHub Releases and was degraded during the compromise window.

VS Code extension from Open VSIX marketplace: AFFECTED — versions 1.8.12 and 1.8.13 contained malicious AI prompt injection code.

Container images (Docker Hub, GHCR): NOT AFFECTED — source code was not modified; container image distributions were not tampered with.

Package manager installs (Homebrew, apt, etc.): NOT AFFECTED — package manager distributions were not impacted by the release deletion or extension compromise.

If your organization uses any of the affected installation methods, the three actions below apply to you immediately.

‍

Vector 1: Broken Release Infrastructure

The most immediate impact was operational. Every CI/CD pipeline that pinned Trivy to a version between v0.27.0 and v0.69.1 via GitHub Releases — the standard installation path — woke up to a broken workflow on March 1. The aquasecurity/trivy-action@0.34.1 GitHub Action, for example, tries to download v0.69.1 from the now-deleted GitHub Release page. It silently fails with exit code 1. Security scanning disappears from the pipeline with no alert.

This is the least dangerous version of the incident — your scanner stops working, but it doesn’t actively hurt you. It’s still a serious problem: the pipeline that should be catching your vulnerabilities is now dark, and most teams won’t notice until someone manually checks the workflow logs.

Vector 2: Malicious Artifact in a Trusted Marketplace

The more dangerous vector was the VS Code extension. The attacker used the stolen PAT to push a modified artifact to the Open VSIX marketplace under Aqua Security’s legitimate publisher account. Developers who installed or auto-updated the Trivy VS Code extension from that marketplace during the window of compromise potentially received a tampered package.

This is a canonical supply chain attack: the malicious artifact bears a legitimate digital signature from a trusted publisher. Standard vulnerability scanners would not flag it — there’s no CVE, no known-bad hash, no advisory. The signal is entirely behavioral.

Vector 3: The Silent Risk of Unverified Scanning Results

The most underappreciated risk is longer-term. Between the initial PAT compromise (Feb 27, 12:01 UTC) and public disclosure (Mar 1), Trivy was running in production pipelines for approximately 36 hours under conditions that no one had visibility into.

Any finding that Trivy didn’t report during that window is now an open question. Did a tampered binary selectively suppress findings? Was the vulnerability database being served from a compromised update path? Aqua Security confirmed no code modification — but organizations relying on Trivy output during that window have to answer these questions before trusting those results for compliance attestation.

What This Means for the Vulnerability Backlog

Our State of Enterprise Vulnerabilities 2026 report documented a finding that becomes more pointed in light of this incident: ~47% of all open findings can be safely dismissed because they describe risks that don’t apply to the actual environment.

The flip side of that insight is equally important: the ~53% that do require action need to be surfaced accurately and urgently. That accuracy depends entirely on the integrity of the tools doing the detecting.

If your scanner was running in a degraded or potentially compromised state during the Trivy incident, the findings it generated — or failed to generate — are unreliable. And in an environment where the average organization carries hundreds of thousands of open findings, the ability to trust your scanner’s output is not a minor operational concern. It is the foundation of every prioritization decision you make.

The compliance implications are significant and underappreciated. SOC 2 Type II audits, ISO 27001 assessments, and FedRAMP authorizations increasingly require organizations to demonstrate that their vulnerability management tooling is itself secure and producing reliable output. If Trivy was running in your environment during the February 27–March 1 window, any compliance attestation based on scan output from that period carries a material question mark. Before relying on that data for audit evidence, re-run the affected scans on a verified clean version (v0.69.2 or later) and document the remediation.

‍

“The vulnerability crisis isn’t a technology problem — it’s a prioritization problem. The data to make smart decisions already exists. Most organizations just aren’t using it yet.” — Zest Security Research, State of Enterprise Vulnerabilities 2026

The Three Actions Every Trivy-Running Organization Should Take Today

1. Verify your installation method and pin to v0.69.2 or later

If you are using aquasecurity/trivy-action, update the version: parameter to v0.69.2 immediately. Do not rely on the default version resolution until all releases in the affected range are confirmed restored. If you are using the install script or get.trivy.dev, pin to v0.69.2 explicitly.

2. Audit VS Code extension installs across your developer fleet

Check whether any developer installed or auto-updated the Trivy VS Code extension from the Open VSIX marketplace during the compromise window (approximately Feb 28–Mar 1). Aqua Security has removed the malicious artifact and revoked the publishing token, but any extension installed from that marketplace during the window should be reinstalled clean from the official VS Code Marketplace.

3. Flag Trivy scan outputs from Feb 27–Mar 1 for review

Treat any automated scan result generated by Trivy between February 27, 00:18 UTC and March 1 as potentially unreliable for compliance attestation purposes. Re-run affected scans on v0.69.2 before relying on that window’s output for compliance or risk reporting.

The Hackerbot-Claw Campaign: Trivy Was Not the Only Target

The Trivy attack did not happen in isolation. The hackerbot-claw campaign — attributed to an autonomous AI agent powered by Claude Opus 4.5 — systematically scanned and exploited vulnerable GitHub Actions workflows across at least seven major open-source repositories between February 20 and March 2, 2026. Five were compromised, including projects from Microsoft, DataDog, and CNCF. The attacker’s own GitHub account claimed to have scanned over 47,000 repositories.

Trivy suffered the most severe impact of any target — full repository takeover rather than the partial code execution achieved elsewhere. The reason: Trivy’s vulnerable workflow exposed a PAT with unusually broad permissions, enabling the attacker to rename the repository, delete releases, and publish a malicious extension under Aqua Security’s legitimate publisher identity.

Notably, one attack in the campaign was stopped when Claude AI detected a prompt injection attempt and refused to comply. The incident illustrates an emerging dynamic: AI-powered attackers operating against AI-assisted defenders, with the security toolchain itself becoming the primary target.

The campaign did not end with Trivy. On March 3, 2026, the official Xygeni GitHub Action (xygeni-action) was separately compromised when an attacker injected a full C2 reverse shell backdoor and silently moved the mutable v5 tag to the malicious commit — affecting every repository referencing @v5 without any visible change to their workflow files. This is a distinct but parallel supply chain attack pattern, and it underscores that the targeting of security tooling is not a one-off event.

‍

The Bigger Picture: Third-Party Scanner Risk as a First-Class Security Problem

The hackerbot-claw campaign targeted seven repositories in seven days. Five were compromised. One of them — Trivy — was a security tool embedded in thousands of production scanning pipelines.

Automated, AI-powered attack bots are targeting the open-source security toolchain specifically because it is trusted by default, integrated deeply into CI/CD pipelines, and rarely subjected to the same scrutiny as production application code.

When attackers start targeting the tools that protect you, the question isn’t just “what vulnerabilities do you have?” It’s “how do you know your answer is right?”

Hardening Your CI/CD Pipeline Against This Attack Class

The pull_request_target pattern that enabled the Trivy compromise is not unique to Trivy. It exists in thousands of open-source and enterprise repositories. The following controls directly address the attack vectors demonstrated in this campaign:

Pin GitHub Actions to Commit SHAs, Not Tags

Tags are mutable — a repository owner (or an attacker who compromises one) can move or delete them at any time. Commit SHAs are immutable. Rather than referencing uses: actions/checkout@v4, pin to the full commit SHA: uses: actions/checkout@b4ffde65f46336ab88eb53be808477a3936bae11. Tools like pin-github-action can automate this across your repository inventory.

Restrict pull_request_target Workflows

Audit every workflow in your repositories for on: pull_request_target triggers. If the workflow checks out PR head code using ref: ${{ github.event.pull_request.head.sha }} or equivalent, it is potentially vulnerable to the Pwn Request pattern. Either remove the head checkout, move secrets to environment protection rules with required reviewers, or convert the workflow to use pull_request (which does not expose repository secrets to fork PRs).

Use Fine-Grained PATs with Minimal Scope

The Trivy compromise was amplified by a PAT with broad repository permissions. Fine-grained Personal Access Tokens — scoped to specific repositories and specific operations — limit the blast radius when a token is stolen. For release and publish workflows, create dedicated tokens that can only write to releases or specific registries. Rotate tokens regularly and monitor for unexpected usage via GitHub audit logs.

These controls are not complex infrastructure changes. They are configuration updates. Organizations that implement them now will also satisfy the supply chain risk management requirements increasingly referenced in SOC 2 and ISO 27001 audits — and will be better positioned as CISA and NIST continue to tighten software supply chain security guidance.

‍

How Zest Approaches This

Zest’s platform tracks the security tooling layer as part of the infrastructure model — not as a separate concern. When a tool like Trivy is flagged as compromised, we can:

• Immediately identify which customers are running it and at what scan frequency
• Surface the affected installation paths (GitHub Action pin, install script, VS Code extension) across the customer environment
• Apply risk context — which customers ran scans during the compromise window, which have VS Code developer toolchains in scope, which are using release download methods that were affected
• Generate actionable remediation steps specific to each customer’s actual configuration, not generic advisory language

Because when your scanner gets hacked, the last thing you need is another finding in a queue of thousands. You need someone who already knows where to look.

‍

Zest Security Research analyzes real-world security telemetry to surface patterns, prioritization frameworks, and actionable intelligence for security teams. All customer references in this post reflect anonymized or aggregated data.

References: - *hackerbot-claw: An AI-Powered Bot Actively Exploiting GitHub Actions — StepSecurity, March 1, 2026 - *Trivy security incident 2026-03-01 — Aqua Security, March 1, 2026 - *State of Enterprise Vulnerabilities 2026 — Zest Security Research, February 2026*