At a glance: A widely used open-source security scanner, Trivy, was compromised in a multistage supply-chain attack, raising concerns because it undermines trust in tools designed to detect risk. Attackers were able to inject malicious code into trusted releases and automation workflows, allowing them to silently steal sensitive credentials from build and deployment pipelines while the tool appeared to function normally.
Threat summary
On March 22, Aqua Security reported that its open-source vulnerability scanner, Trivy, had been compromised in a multistage supply-chain attack that began weeks earlier.
Trivy is widely used across the software industry to scan containers, cloud environments, and code repositories. Many organizations, including managed service providers, integrate Trivy into automated build and deployment workflows. Because the tool is trusted and deeply embedded in these processes, a compromise can have broad consequences.
The compromise became known on March 19 when a threat actor leveraged compromised credentials to publish malicious releases of Trivy version 0.69.4. They also published altered versions of trivy-action and setup-trivy, automation tools commonly used by organizations to run Trivy as part of software build and deployment processes.
Earlier in the month, before the breach was confirmed, researchers had already observed suspicious outbound traffic from newly installed Trivy instances. Around the same time, there were reports of Docker images on Docker Hub with no matching GitHub releases, signaling that the uploads were unauthorized.
By March 22, multiple research teams concluded that the attackers were executing a coordinated supply-chain attack that moved through several stages:
-
Compromising GitHub Actions
-
Altering official releases
-
Pushing malicious Docker images
Rather than introducing a new, obviously suspicious version, the threat actors modified existing version tags associated with trivy-action, injecting malicious code into workflows that organizations were already running. Because many CI/CD pipelines rely on version tags instead of pinned commits, these pipelines continued to run normally, unaware that the underlying code had changed.
In affected environments, the payload executed before any legitimate Trivy scanning logic. This meant workflows appeared to complete successfully while silently exfiltrating sensitive information. The malware was designed to collect API tokens, cloud credentials for AWS, GCP, and Azure, SSH keys, Kubernetes tokens, Docker configuration files, Git credentials, and other secrets commonly present in CI/CD systems. The stolen data was sent to attacker-controlled infrastructure through two exfiltration paths identified by researchers.
Aqua Security has confirmed that its commercial products, including the version of Trivy embedded within the Aqua Platform, were not affected by this compromise. Aqua’s commercial supply chain, build systems, and container registries were not part of the compromise, and the versions of Trivy embedded within the Aqua Platform remain secure. The incident affected only the open‑source Trivy ecosystem distributed independently of Aqua’s commercial offerings.
This exposure applies only to users who downloaded or executed the compromised open‑source Trivy components during the affected period, including GitHub releases, GitHub Actions integrations, and Docker images pulled from public registries. Users who rely solely on Trivy within the Aqua Platform are not considered affected.
Analysis
The threat actors exploited Trivy’s position as a trusted security tool. Because Trivy often runs with elevated access, the embedded malware was able to collect sensitive credentials while appearing to function normally. This allowed the threat actors to bypass basic endpoint protections and take advantage of automated pipelines that download and run Trivy without manual review.
The impact is significant for organizations that downloaded Trivy artifacts between early March and March 22. The stolen credentials can enable unauthorized access to cloud platforms, Kubernetes clusters, and continuous integration systems.
MSPs face elevated exposure because they often run shared scanning and validation workflows across multiple client environments. A compromise in one place can therefore create opportunities for attackers to move across several tenants.
Those who consumed open‑source Trivy directly should follow the recommended remediation steps, including reinstalling Trivy only from verified sources and validating all binaries and container images against official signatures. Any system that ran a compromised version would benefit from reimaging and rotating all cloud, registry, and orchestration credentials. Restricting outbound traffic from build and scanning systems reduces data‑exfiltration risk. Adding signature checks to automated pipelines and separating build infrastructure from production environments helps limit exposure to similar supply‑chain attacks.