The Trivy supply chain attack exposed a critical vulnerability in how developers trust open-source security tools. On March 19, 2026, attackers used compromised credentials to hijack Aqua Security’s Trivy repository, forcing malicious code into versions used by over 10,000 GitHub workflows worldwide.
Key Takeaways
- Attackers force-pushed malicious code into 76 of 77 Trivy-action version tags and all 7 setup-trivy tags on March 19, 2026.
- Malicious Trivy v0.69.4 binary stole API tokens, AWS/GCP/Azure credentials, SSH keys, and Kubernetes tokens from CI/CD systems.
- Data was exfiltrated to a fake domain (scan.aquasecurtiy[.]org) before legitimate scanning occurred.
- This marks the second Trivy compromise within a month, escalating supply chain risks for widely used development tools.
- Attackers defaced all 44 Aqua Security GitHub repositories using scripted API calls within two minutes.
How the Trivy supply chain attack unfolded
The Trivy supply chain attack followed a methodical sequence designed to maximize impact while minimizing detection. Attackers first compromised credentials—including the aqua-bot service account and Argon-DevOps-Mgt with admin access—likely stolen during a previous Trivy incident. Seven hours before the main assault, they tested the stolen token by creating and immediately deleting a branch, confirming write access without triggering alarms.
At approximately 17:43 UTC on March 19, the attackers executed their full assault. They force-pushed 76 of 77 version tags in aquasecurity/trivy-action and all 7 tags in aquasecurity/setup-trivy to point to malicious commits. Simultaneously, release automation triggered the deployment of a poisoned Trivy v0.69.4 binary across Docker Hub, GitHub Container Registry, and Amazon ECR. The exposure window for trivy-action lasted roughly 12 hours; setup-trivy remained compromised for approximately 4 hours; and the malicious binary circulated for about 3 hours before removal.
According to Philipp Burckhardt, a security researcher at Socket, the attackers exploited the trust developers place in version tags: “We identified that an attacker force-pushed 75 out of 76 version tags in the aquasecurity/trivy-action repository… effectively turning trusted version references into a distribution mechanism for an infostealer”. This approach bypassed many automated security checks because the malicious code appeared to come from legitimate version references rather than new, unvetted releases.
What the malware actually stole
The infostealer payload embedded in the Trivy supply chain attack executed before legitimate scanning began, giving it access to the full CI/CD environment. It systematically harvested API tokens, cloud credentials for AWS, GCP, and Azure, SSH keys, Kubernetes tokens, Docker configurations, Git credentials, and environment variables. All stolen data was encrypted and exfiltrated via HTTP POST requests to a fake domain mimicking Aqua Security: scan.aquasecurtiy[.]org.
The attack did not stop at one-time credential theft. On developer machines, the malware deployed a systemd service running sysmon.py that continuously polled an external server for additional payloads, establishing persistence. This two-stage approach—immediate exfiltration plus persistent backdoor—suggests the attackers intended long-term access to compromised systems, not merely a one-off credential grab.
CrowdStrike detected the Trivy supply chain attack through a spike in suspicious script executions across Falcon customers, providing early warning to organizations monitoring endpoint activity. However, organizations relying solely on Trivy for security scanning would have seen the malicious version appear as a routine update, making detection significantly harder without external threat intelligence.
Repository defacement and escalation
After stealing credentials, the attackers pivoted to maximum disruption. Using scripted API calls, they defaced all 44 Aqua Security GitHub repositories in approximately 2 minutes, renaming repositories and altering descriptions. This rapid, automated escalation demonstrated that the attackers had not just compromised a single service account—they had obtained admin-level access across the entire Aqua Security organization on GitHub.
The defacement served multiple purposes: it signaled the breach to the security community, forced Aqua Security into incident response mode, and potentially distracted from the more dangerous credential theft happening silently in CI/CD pipelines. Organizations that discovered the Trivy supply chain attack through the defaced repositories had already been exposed; the visible damage was a consequence, not the primary attack vector.
Why this is the second Trivy compromise in a month
The Trivy supply chain attack represents an escalation in supply chain targeting. This marks the second compromise of Trivy within approximately one month, according to multiple security researchers. The first incident likely provided the attackers with the credentials they weaponized in the March 19 assault, turning Trivy from a security tool into a persistent threat delivery mechanism.
The rapid succession of breaches suggests either inadequate credential rotation at Aqua Security or a sophisticated, persistent attacker with multiple entry points into the organization. Either scenario is alarming for the 10,000+ GitHub workflows that reference aquasecurity/trivy-action, as they face compounding risk from repeated compromises of the same trusted tool.
What organizations should do now
If your CI/CD pipelines use aquasecurity/trivy-action or aquasecurity/setup-trivy, immediate action is required. Rotate all API tokens, cloud credentials, SSH keys, and Kubernetes tokens that may have been exposed. Audit CI/CD logs between March 19 and the time you updated to patched versions to identify any unauthorized access or data exfiltration.
Check for the systemd service sysmon.py on developer machines and build servers, and remove it if found. Update to Trivy version 0.69.7 or later, and pin your GitHub Actions to specific commit hashes rather than version tags, reducing the window for tag-based attacks. Consider implementing additional credential scanning in your CI/CD pipelines using tools that do not rely on a single third-party vendor.
How does Trivy compare to other vulnerability scanners?
Trivy is positioned as a free, open-source alternative to proprietary vulnerability scanners. Its widespread adoption—reflected in the 10,000+ workflows using trivy-action—stems from its ease of integration with GitHub Actions and support for multiple artifact types (Docker images, Kubernetes manifests, source code). However, the Trivy supply chain attack underscores a critical trade-off: open-source tools offer transparency and cost savings but introduce supply chain risk if the maintainers’ infrastructure is compromised. Proprietary scanners, while closed-source, typically operate within more controlled deployment environments and may offer faster incident response due to dedicated security teams.
Is Trivy still safe to use after the supply chain attack?
Yes, Trivy remains safe if you use patched versions (0.69.7 and later) and follow credential rotation practices. The Trivy supply chain attack was a credential theft targeting the Aqua Security organization, not a fundamental flaw in Trivy’s scanning logic. Aqua Security has removed malicious artifacts from GitHub Releases, Docker Hub, GHCR, and ECR, and repointed compromised tags to safe commits. However, trust in the tool’s distribution chain has been damaged, so pinning to specific commit hashes rather than version tags adds an extra layer of protection.
What should I check in my CI/CD logs after the Trivy supply chain attack?
Review logs between March 19 and when you patched for any unusual API calls, unexpected credential access, or data exfiltration attempts. Look for POST requests to scan.aquasecurtiy[.]org (the fake domain) or systemd service creation events. If you see evidence of the infostealer running, assume all secrets used in that CI/CD environment have been compromised and rotate them immediately.
The Trivy supply chain attack is a watershed moment for open-source security tooling. It proves that even tools designed to find vulnerabilities can become vectors for attack if the maintainers’ credentials are compromised. The solution is not to abandon open-source scanning—it is to treat every third-party tool, no matter how trusted, as a potential attack surface. Rotate credentials regularly, pin to commit hashes, and monitor for unusual activity. Complacency is the real vulnerability.
Edited by the All Things Geek team.
Source: TechRadar
