Overview

A major supply chain attack has compromised the widely used Trivy vulnerability scanner, turning a trusted security tool into a malware delivery mechanism. Threat actors injected an infostealer payload into official releases and GitHub Actions, impacting CI/CD pipelines across thousands of projects.

The attack highlights a dangerous shift: security tools themselves becoming attack vectors, enabling adversaries to silently extract sensitive credentials from development environments.

What Happened?

The breach targeted Trivy’s GitHub ecosystem, including:

• trivy-action (GitHub Action for CI/CD scans)

• setup-trivy (installation helper action)

• The Trivy binary itself

Attackers force-pushed malicious code into existing version tags, meaning developers unknowingly executed compromised versions without changing their workflows.

A backdoored release, v0.69.4, was also published, containing a hidden infostealer that executed alongside legitimate scanning operations.

Attack Summary

How the Attack Worked

1. Compromised Credentials

Attackers leveraged previously stolen credentials from an earlier breach that were not fully rotated, allowing continued access to the repository.

2. Tag Poisoning in GitHub Actions

Instead of creating new releases, attackers force-pushed 75 out of 76 version tags to malicious commits.

This meant:

• Existing workflows remained unchanged

• Trusted version tags now pointed to malicious code

• Detection became extremely difficult

3. Silent Execution in CI/CD Pipelines

The malicious code was embedded inside GitHub Actions and executed before the legitimate scan, ensuring:

• Normal scan results still appeared

• No obvious signs of compromise

4. Infostealer Deployment

The payload harvested sensitive data from CI/CD environments, including:

• API keys and tokens

• SSH keys

• Cloud credentials

• Kubernetes secrets

• Docker and Git configurations

It then encrypted and exfiltrated the data to attacker-controlled infrastructure.

Why This Attack Is Dangerous

This incident is particularly critical because:

• Security tools were weaponized — breaking trust assumptions

• CI/CD pipelines hold high-value secrets, making them prime targets

• Tag-based versioning was exploited, a common industry practice

• The attack was stealthy, running alongside legitimate processes

In essence, organizations were compromised while running a security scan.

Indicators of Compromise (IOCs)

Security teams should look for:

• Use of Trivy version 0.69.4

• Unexpected outbound traffic from CI/CD runners

• Unauthorized repositories (e.g., used for data staging)

• Suspicious environment variable access or memory reads

Mitigation & Recommendations

Immediate Actions

• Rotate all CI/CD secrets and credentials

• Revoke and regenerate GitHub tokens

• Audit pipelines for compromised runs

Long-Term Security Measures

• Pin GitHub Actions to commit SHAs (not tags)

• Apply least-privilege access to CI/CD tokens

• Monitor runtime behavior of pipelines

• Treat security tools as high-risk dependencies

Key Takeaways

• Supply chain attacks are evolving beyond dependencies to tooling infrastructure

• CI/CD pipelines are a critical attack surface

• Trust in version tags alone is no longer sufficient

• Continuous monitoring and strict credential hygiene are essential

Final Thoughts

This attack is a wake-up call: even trusted security tools can become attack vectors.

Organizations must shift from trust-based security to verification-based security, especially in CI/CD environments where a single compromised component can expose an entire infrastructure.

At ClearPhish, we emphasize human-centric cybersecurity awareness alongside technical controls — because recognizing unusual behavior is often the first line of defense in modern supply chain attacks.

Disclaimer: ClearPhish maintains a strict policy of not participating in the theft, distribution, or handling of stolen data or files. The platform does not engage in exfiltration, downloading, hosting, or reposting any illegally obtained information. Any responsibility or legal inquiries regarding the data should be directed solely at the responsible cybercriminals or attackers, as ClearPhish is not involved in these activities. We encourage parties affected by any breach to seek resolution through legal channels directly with the attackers responsible for such incidents.