Trivy Compromised Again: From Supply Chain Attack to Full Credential Harvesting

Over the past few weeks, Trivy has already been at the center of a supply chain security incident. That earlier compromise raised concerns about how attackers could manipulate release pipelines and distribute malicious artifacts through trusted channels.

The previous incident involved the Trivy VSCode extension (version 1.8.12), distributed via the OpenVSX marketplace, which contained malicious code designed to leverage local AI coding agents to collect and exfiltrate sensitive information.

The latest incident, involving version 0.69.4, introduces a different class of risk — one that moves beyond developer workstation targeting into active credential extraction within CI/CD environments.

The malicious release contained binaries that beaconed to a typosquatted C2 domain:

scan[.]aquasecurtiy[.]org

The aquasecurity/setup-trivy GitHub Action was also compromised, extending the impact to CI/CD pipelines that may have pulled the affected version automatically.

At Daylight, we identified and analyzed a malicious Trivy release, version 0.69.4, that was actively deployed in the wild. What initially appeared to be another callback-style compromise quickly revealed itself to be something much broader.

What was compromised

The affected release, Trivy v0.69.4, contained trojanized binaries that attempted to communicate with a typosquatted domain: scan[.]aquasecurtiy[.]org

The domain closely resembles the legitimate Aqua Security domain, differing by a single misplaced character. This type of infrastructure is commonly used to evade casual inspection while maintaining plausibility.

In parallel, the aquasecurity/setup-trivy GitHub Action was also compromised. This significantly increases the potential impact, as many CI/CD pipelines rely on this action and may pull updates automatically without strict version pinning.

From beacon to infostealer

Initial indicators suggested a relatively standard pattern: execution of a malicious binary followed by outbound communication to a command-and-control endpoint.

However, analysis of the modified GitHub Action revealed that the payload was not limited to beaconing. It implemented a comprehensive credential harvesting routine.

The behavior was systematic. The payload enumerated and attempted to collect:

• SSH private keys from user directories
• AWS credentials, including access via the IMDSv1 metadata endpoint
• Kubernetes configuration files and service account tokens
• Environment variable files across the filesystem
• Google Cloud and Azure credentials
• Docker registry authentication data
• Tokens from npm, .netrc, and Vault configurations
• Database credentials for common systems such as MySQL, Postgres, Redis, and LDAP
• Cryptocurrency wallet keys
• Shell history files
• System account data, including /etc/passwd and /etc/shadow

This level of coverage indicates the intent was not targeted access, but complete extraction of any credential material available to the runtime environment.

Exfiltration design

The primary exfiltration method was an HTTP POST request to the attacker-controlled infrastructure.

What stands out is the fallback mechanism. If outbound communication failed, the payload attempted to create a public GitHub repository named tpcp-docs and upload the collected data there.

This approach removes the attacker’s dependency on their own infrastructure and increases the likelihood that data leaves the environment, even in restricted network conditions. It also introduces a secondary risk: exposed data may be publicly accessible and indexed.

Scope of impact

Any environment that executed Trivy v0.69.4 should be considered compromised.

This includes not only the CI runner itself, but any system, service, or account whose credentials were accessible during execution. In most CI/CD environments, that scope is broad by design. It often includes cloud credentials, deployment keys, registry access, and internal service authentication.

As a result, the effective blast radius extends well beyond a single pipeline run.

Detection and investigation

In response to this incident, we conducted threat hunting across client environments using four primary signals:

• DNS queries to the typosquatted domain scan[.]aquasecurtiy[.]org
• Outbound connections to the IP address 45.148.10.212, associated with hosting in Amsterdam
• Execution telemetry indicating use of Trivy v0.69.4 on CI runners or endpoints
• CI/CD pipeline configurations using aquasecurity/setup-trivy that may have pulled the compromised release

These signals provide a starting point for identifying potentially affected systems, but should not be considered exhaustive.

Indicators of compromise

The following indicators were observed in this incident and can be used for detection and scoping:

• IP address: 45.148.10.212
• Domain: scan[.]aquasecurtiy[.]org
• GitHub repository name: tpcp-docs

These indicators should be correlated with execution telemetry and access logs to identify potentially affected systems.

Recommended actions

Organizations using Trivy in CI/CD pipelines should take immediate steps to contain and assess potential exposure:

• Pin Trivy to version 0.69.3 and avoid using floating tags
• Identify any pipeline executions involving setup-trivy during the affected window on March 19 between approximately 17:43 UTC and 23:13 UTC
• Search for DNS and network indicators associated with the malicious infrastructure
• Audit GitHub accounts and organizations for unexpected public repositories named tpcp-docs
• Rotate all credentials that were accessible from affected runners
• Rebuild CI environments from clean, trusted images

Broader implications

This incident highlights a recurring pattern in modern supply chain attacks. Rather than exploiting vulnerabilities in application code, attackers are targeting the systems and tools that sit upstream in the development process.

Security tooling, in particular, presents a high-value target. These tools are widely trusted, frequently automated, and often granted extensive access to sensitive environments.

The shift is subtle but important. The question is no longer only whether dependencies are vulnerable. It is whether the mechanisms used to validate and secure those dependencies can themselves be trusted at runtime.

As this incident demonstrates, that trust can be leveraged quickly and at scale.

‍