Trivy Scanner Compromised: Credential-Stealing Backdoor Exposes CI/CD Secrets

Overview/Introduction

On March 21, 2026, Aqua Security’s open-source vulnerability scanner Trivy was disclosed as the latest victim of a sophisticated supply-chain attack. Threat actors infiltrated Trivy’s build and release infrastructure, embedding a covert credential-stealing payload into the official trivy binary as well as the supporting trivy-action and setup-trivy GitHub Actions. The malicious artifacts were published to GitHub releases, Docker Hub, the GitHub Container Registry (GHCR), and Amazon Elastic Container Registry (ECR), reaching thousands of CI/CD pipelines worldwide.

Unlike classic ransomware or remote code execution exploits, this compromise targets the very secrets that developers trust their build systems to protect. By running the backdoored scanner, pipelines silently leak cloud provider keys, Docker registry credentials, Kubernetes service-account tokens, SSH keys, and even cryptocurrency wallet files to attacker-controlled servers.

Technical Details (CVE, attack vector, exploitation method)

At the time of writing, the vulnerability has not yet been assigned a CVE identifier; the community expects a placeholder such as CVE-2026-XXXXX to be issued once the full advisory is published. The attack chain can be broken into three distinct phases:

• Initial foothold: Threat actors leveraged a previously disclosed compromise of Trivy’s GitHub Actions workflow (reported late February 2026). The earlier breach left lingering credentials that the attackers reused to gain read/write access to the repository and the CI environment.
• Supply-chain injection: Using the compromised CI runner, the attackers modified the build scripts for the Trivy binary and the two supporting actions. They added a Go module (stealer) that executes in parallel with Trivy’s legitimate scanning process.
• Payload execution & exfiltration: When the malicious binary runs, it:
  1. Spawns the authentic Trivy service to avoid detection.
  2. Enumerates process memory of the runner to capture any in-memory secrets (e.g., GitHub token variables, AWS_SESSION_TOKEN).
  3. Recursively scans common secret locations: ~/.ssh, ~/.aws/credentials, /etc/kubernetes/kubelet.conf, Docker config files, and wallet directories.
  4. Compresses and encrypts the harvested data using a hard-coded AES-256 key.
  5. Sends the payload to a typosquatted domain (aquasecure.com) that mimics Aqua Security’s official site. If the primary channel fails, the malware creates a public GitHub repository and pushes the encrypted blob as an artifact.

The malicious code is written in Go, compiled into the same binary as Trivy, making static analysis difficult without signature verification. The backdoor is deliberately lightweight (≈ 12 KB) to avoid raising suspicion from size-based heuristics.

Impact Analysis

The compromise has a critical severity rating for several reasons:

• Broad adoption: Trivy boasts over 32,000 GitHub stars and more than 100 million Docker Hub pulls. It is the de-facto scanner for container images, filesystems, and Infrastructure-as-Code (IaC) templates across enterprises.
• CI/CD reach: The infected trivy-action and setup-trivy actions are referenced in thousands of public and private repositories. Any workflow that automatically installs Trivy via these actions may have executed the malicious binary.
• Secret exposure: The payload targets high-value credentials. Compromise of cloud API keys can lead to full account takeover, data exfiltration, and ransomware deployment. SSH keys and Kubernetes tokens provide lateral movement within the target environment.
• Chain reaction potential: Stolen secrets can be used to inject further supply-chain attacks into downstream projects that consume the same images or IaC templates, amplifying the impact.

Enterprises that rely on Trivy for nightly security scans, as well as development teams that embed the scanner in pull-request pipelines, are directly affected. Even organizations that only used the Docker image of Trivy (e.g., aquasec/trivy:latest) may have pulled a compromised layer.

Timeline of Events

• Feb 24 2026: Initial breach of Trivy’s GitHub Actions workflow reported by security researchers (incomplete credential rotation).
• Mar 03 2026: Attackers gain persistent access to the CI environment, modify build scripts, and push malicious commits.
• Mar 09 2026: Malicious artifacts are published to GitHub releases (tags 0.34.2, 0.33.0, 0.18.0, etc.), Docker Hub, GHCR, and ECR.
• Mar 15 2026: First signs of abnormal outbound traffic observed by a few organizations; internal investigation begins.
• Mar 21 2026: Trivy maintainers publicly disclose the supply-chain compromise, release emergency advisory, and publish a clean, signed binary (v0.35.1).
• Mar 22 2026 onward: Security firms Socket and Wiz publish detailed analyses; affected parties begin mitigation.

Mitigation/Recommendations

Immediate actions are required to contain the breach and prevent further credential leakage:

1. Verify binary signatures: Use cosign or gpg to validate the signature of any Trivy binary, Docker image, or GitHub Action before execution. Reject any unsigned or mismatched artifacts.
2. Update to the patched release: Replace all Trivy installations with version 0.35.1 or later, which removes the backdoor and includes a hardened build pipeline.
3. Rotate all secrets: Treat every secret used in CI/CD pipelines as compromised. Regenerate API keys, cloud provider credentials, Docker registry passwords, Kubernetes service-account tokens, and SSH keys. Update secret stores (e.g., HashiCorp Vault, AWS Secrets Manager) with the new values.
4. Audit CI runners: Review runner configurations for rogue binaries, unexpected network connections, or unknown scheduled jobs. Re-image runners from trusted base images.
5. Enable provenance checks: Adopt SLSA level 2 or higher for all build artifacts. Enforce --provenance verification in pipelines.
6. Implement network egress controls: Block outbound traffic from CI runners to unknown domains. Whitelist only required endpoints (e.g., Docker Hub, internal registries).
7. Monitor for exfiltration patterns: Deploy IDS/IPS rules to detect encrypted POST requests to suspicious domains similar to aquasecure.com. Use SIEM correlation for sudden spikes in outbound data from build agents.

Real-World Impact

Organizations that adopted Trivy as part of a “shift-left” security model are now forced to reassess their trust in open-source supply-chain integrity. The breach demonstrates how a single compromised tool can expose an entire ecosystem of secrets, potentially enabling:

• Unauthorized creation of cloud resources (e.g., EC2 instances, GCP projects) for crypto-mining or data theft.
• Deployment of malicious containers into production environments, bypassing traditional image-signing checks.
• Privilege escalation within Kubernetes clusters by leveraging stolen service-account tokens.
• Supply-chain propagation when downstream projects embed the infected Trivy image in their own CI pipelines.

For companies that rely on continuous scanning to satisfy compliance (PCI-DSS, ISO 27001), the incident introduces a compliance gap-any audit that discovers un-rotated credentials will flag a violation. Moreover, the incident erodes confidence in the open-source security tooling supply chain, prompting many security teams to demand signed releases and reproducible builds as a baseline requirement.

Expert Opinion

From a senior analyst’s perspective, this attack marks a watershed moment for supply-chain security. The attackers demonstrated patience: after an initial breach they waited weeks, performed credential hygiene checks, and returned to embed a second-stage payload that specifically targets secrets. This “credential-first” approach is a departure from classic code-injection attacks that aim for remote code execution; it reflects a mature threat actor’s focus on data exfiltration and lateral movement.

The choice of Trivy is strategic. Its ubiquity in CI pipelines gives the adversary a “low-friction” path to thousands of environments with a single compromised binary. The attack also underscores the importance of “defense-in-depth” for CI/CD: merely signing binaries is insufficient if the signing process itself is compromised. Organizations must enforce provenance verification, immutable build pipelines, and strict secret-handling policies (e.g., “no secrets on runners”).

Looking forward, I expect a wave of similar attacks on other popular security-related open-source tools (e.g., Syft, Grype, TruffleHog). Vendors and maintainers should adopt reproducible builds, provide transparent SBOMs, and integrate with tools like cosign by default. The community must also treat supply-chain incidents as a shared responsibility: rapid disclosure, coordinated CVE issuance, and automated remediation pipelines will be key to limiting damage.