Trivy, one of the most widely deployed open-source vulnerability scanners in the world, has been compromised in a sophisticated supply chain attack. Threat actor TeamPCP injected credential-stealing malware into official Trivy releases, GitHub Actions, and container registry artifacts; turning a tool designed to find secrets in CI/CD pipelines into a tool that steals them. Trivy maintainer Itay Shakury confirmed the breach on GitHub, urging any organization that ran a compromised version to treat all pipeline secrets as fully compromised and rotate immediately. The attack was traced and analyzed by security firms Socket and Wiz.

What Happened

Attackers compromised three core components of the Trivy project simultaneously: trivy-action (the official GitHub Action for running Trivy scans), setup-trivy (a helper action for installing the scanner), and the Trivy binary itself. Backdoored artifacts were pushed to GitHub Releases, Docker Hub, GitHub Container Registry, and Amazon Elastic Container Registry; every major distribution channel Trivy uses.

The scale of the tag compromise is severe. According to Socket's analysis, 75 of 76 version tags in trivy-action were overwritten with malicious code, along with seven tags in setup-trivy. The only clean trivy-action tag was version 0.35.0. Widely pinned versions (including 0.34.2, 0.33.0, and 0.18.0) were all backdoored.

The root cause traces to an earlier supply chain compromise disclosed the previous month, which also exploited insecure GitHub Actions across multiple projects. Trivy's team performed credential rotation after that first incident; but the rotation was incomplete. TeamPCP retained enough access to return to Trivy's environment, introduce malicious commits, and overwrite release artifacts across distribution channels. Socket and Wiz independently confirmed the link between the two incidents.

The malicious binary operates with particular stealth: when executed, it runs both the legitimate Trivy service and the malicious credential-stealing code in parallel. From the perspective of the CI/CD workflow, Trivy appears to be functioning normally while simultaneously exfiltrating secrets in the background.

What Was Taken

The credential stealer was specifically engineered to target the secrets available in CI/CD environments; the highest-value targets in a developer pipeline:

The specific volume of exfiltrated data across all affected organizations has not been quantified. Given Trivy's install base (over 32,000 GitHub stars and more than 100 million Docker Hub downloads) the potential scope of affected pipelines is enormous. Any organization that ran a compromised tag during the exposure window should assume their pipeline secrets were captured.

Why It Matters

This attack is a textbook demonstration of why the software supply chain is the most dangerous attack surface in modern infrastructure; and why security tooling itself is a high-value target.

Trivy is not a general-purpose utility. It is a security tool, deployed specifically in security-critical contexts: vulnerability scanning pipelines, container image audits, secret detection workflows. Organizations that trust Trivy implicitly do so precisely because they believe it is a security control. Compromising that tool doesn't just steal credentials; it defeats the psychological and procedural defenses that organizations have built around it.

The parallel execution technique, running legitimate Trivy alongside the malicious payload, is a particularly dangerous evasion approach. Security teams reviewing pipeline logs would see successful Trivy scans completing normally. There is no failed execution, no anomalous error output, no obvious indicator of compromise unless teams are specifically monitoring for outbound network connections from their scanner processes.

The incomplete credential rotation after the first breach is the systemic failure that enabled the second. This is a recurring pattern in supply chain attacks: the first incident triggers a response that is thorough enough to feel complete, but leaves residual access that a patient adversary exploits for re-entry. Every organization should treat credential rotation as a complete-or-nothing operation.

The blast radius extends beyond Trivy itself. CI/CD secrets, particularly cloud provider credentials and Kubernetes configs, are master keys. An attacker with AWS access keys from a development pipeline can pivot to production infrastructure, exfiltrate data, deploy backdoored workloads, or establish persistent access in cloud environments that persists long after the initial pipeline compromise is remediated.

The Attack Technique

TeamPCP exploited a chain of GitHub Actions security weaknesses across two linked incidents:

Stage 1; Initial compromise: TeamPCP exploited insecure GitHub Actions configurations (likely workflow injection or compromised personal access tokens) to gain write access to Trivy's repository and release pipeline. This mirrors a broader campaign the group ran against multiple open-source projects simultaneously.

Stage 2 (Incomplete remediation: Trivy maintainers rotated credentials after the first incident, but the rotation was incomplete) at least one access pathway remained active. TeamPCP retained the ability to write to the repository and distribution channels.

Stage 3; Artifact poisoning: Using retained access, attackers overwrote 75 of 76 version tags in trivy-action and 7 tags in setup-trivy with malicious versions. They simultaneously backdoored the Trivy binary itself and pushed poisoned artifacts to all four distribution channels.

Stage 4; Parallel execution credential theft: The malicious binary launches the legitimate Trivy process alongside a credential stealer, which reads process memory, traverses the filesystem for key material, and exfiltrates captured secrets to attacker-controlled infrastructure.

This attack maps to MITRE ATT&CK T1195.001 (Supply Chain Compromise: Compromise Software Dependencies), T1552.001 (Credentials in Files), T1003 (OS Credential Dumping), and T1567 (Exfiltration Over Web Service).

What Organizations Should Do

  1. Rotate all pipeline secrets immediately if you ran any Trivy tag other than 0.35.0. This is not optional and not a precaution; it is incident response. Every secret that transited a GitHub Actions runner using a compromised Trivy version should be treated as compromised: AWS keys, GCP service accounts, Kubernetes tokens, SSH keys, registry credentials, API tokens. Rotate all of them. Do it now, before finishing this article.

  2. Audit all GitHub Actions dependencies and pin to verified commit SHAs; not version tags. Tags are mutable. A tag you pinned last month can be silently overwritten, as this attack demonstrates. Pin all third-party Actions to immutable full-length commit SHAs (uses: aquasecurity/trivy-action@<full-sha>). Tools like tj-actions/changed-files (compromised in a prior supply chain attack) have demonstrated this repeatedly. The industry needs to move off tag pinning entirely.

  3. Restrict CI/CD secrets to minimum necessary scope. If a pipeline secret can access production infrastructure, it should not be present in a general-purpose scanning workflow. Segment pipeline secrets by function. Scanning pipelines should not have write access to production, deployment credentials, or master infrastructure keys. Least privilege in CI/CD is not a nice-to-have.

  4. Review pipeline logs for the exposure window. Identify every workflow run that executed trivy-action, setup-trivy, or the Trivy binary between the first breach (late February 2026) and the disclosure (March 21, 2026). For each run, audit what secrets were injected into the environment. That list is your rotation scope.

  5. Monitor for anomalous outbound connections from CI/CD runners. The credential stealer exfiltrates data over the network. If your runner environment supports network egress monitoring, look for unexpected outbound connections during Trivy execution windows. Going forward, implement network egress controls on CI/CD runners; scanners should not need broad internet access to do their job.

  6. Treat security tooling vendors with the same supply chain rigor as application dependencies. Security tools (scanners, SCA tools, SAST engines) are deployed with elevated trust and access. They are high-value targets precisely because of that trust. Require the same artifact signing, SBOM availability, and integrity verification from your security vendor toolchain that you demand from application dependencies.

Sources