Trivy GitHub Action compromise exposed CI/CD secrets in a stealth supply-chain attack

A supply-chain compromise in Aqua Security’s aquasecurity/trivy-action shows how quickly trust can collapse inside CI/CD. According to CrowdStrike, attackers retroactively repointed 76 of 77 release tags so that workflows pulling the action by tag downloaded a malicious entrypoint.sh before running the legitimate scanner. The result was a quiet credential theft operation on GitHub-hosted and self-hosted runners, with the security scan still appearing to complete normally.

That combination matters because CI/CD runners often hold exactly the material attackers want: cloud credentials, deployment tokens, SSH keys, Kubernetes secrets, package registry access, and other sensitive values stored for automation. In other words, the scanner became the intrusion path.

Why this Trivy incident is different

This is not a routine bug story or a single-CVE disclosure. It is a software supply-chain compromise built around mutable Git references. Many teams reference GitHub Actions by human-friendly version tags such as @0.24.0, but tags can be force-moved to a different commit without any obvious change on the release page. In this case, that let the attacker preserve trust at the workflow level while silently swapping in malicious code.

CrowdStrike said the poisoned action prepended roughly 100 lines of attacker-controlled logic before the real Trivy workflow. After collecting secrets and staging data, the script handed execution back to the legitimate scanner. For many defenders, that makes the operational takeaway more important than the headline: successful CI/CD abuse can look normal unless you monitor runner behavior, process trees, outbound traffic, and credential usage.

What the payload did on runners

The malicious logic behaved like targeted malware designed for build environments.

On GitHub-hosted Linux runners, the code reportedly used a Base64-decoded Python component with elevated execution to inspect runner memory and extract GitHub Actions secrets. On self-hosted runners, the attacker shifted to broader filesystem harvesting, targeting assets such as:

• SSH keys and configs
• AWS, GCP, and Azure credentials
• Kubernetes configs and service account tokens
• Docker registry credentials
• database credentials
• .env secrets and API keys
• TLS private keys
• shell histories and system files

Collected data was then staged with encryption, using AES-256-CBC for the payload and RSA-4096 to wrap the session key. CrowdStrike reported primary exfiltration to the typosquatted domain scan.aquasecurtiy[.]org, with a fallback path that abused an available GitHub token to create a public repository and upload the encrypted archive as a release asset.

The compromise was broader than one action

The blast radius extended beyond trivy-action. Reporting from CrowdStrike and follow-up analysis from Aqua, Wiz, and Snyk indicate the incident also affected setup-trivy and Trivy v0.69.4. CrowdStrike said the compromised Trivy binary dropped a delayed Python loader that later contacted blockchain-hosted command-and-control infrastructure on the Internet Computer to fetch follow-on payloads.

That matters because the incident was not limited to a single CI step. It touched the surrounding trust chain: the action, the setup helper, and the scanner binary itself. For defenders, that means remediation has to cover version selection, runner exposure, secret hygiene, artifact review, and post-compromise credential abuse—not just “switch to a fixed release” and move on.

What defenders should do now

Three priorities stand out.

1. Rotate exposed secrets aggressively

Any secret accessible to affected runners should be treated as potentially exposed. That includes GitHub tokens, cloud credentials, Kubernetes tokens, SSH keys, package registry credentials, and values stored in .env files. Rotation should happen before teams assume the incident is closed.

2. Pin GitHub Actions to immutable commit SHAs

The central lesson here is that tags are convenient but not trustworthy enough for high-value CI/CD dependencies. Pinning actions to full commit SHAs sharply reduces the risk of tag repointing attacks. It also makes review and change control much easier for incident response teams.

3. Hunt for runner-side abuse and unusual token activity

Review workflow executions around the reported exposure window, inspect logs for suspicious shell and Python execution, and look for unusual outbound requests or token reuse from unfamiliar hosts, geographies, or repositories. This is where threat intelligence becomes practical: IOC matching is useful, but behavior-based review of build systems is even more important.

Strategic takeaway

The Trivy incident is a useful reminder that software supply-chain defense is not only about package registries and developer endpoints. CI/CD itself is part of the attack surface, and the tooling that teams trust to scan their environments can become the delivery mechanism if that trust chain is compromised.

For most organizations, the immediate lesson is simple: treat pipelines like production assets. If a runner can access secrets, infrastructure, and deployment paths, then compromise of a single action can become compromise of the wider environment. Defensive maturity here means immutable references, tighter secret scoping, stronger runner monitoring, and faster credential rotation when something looks off.

References

1. CrowdStrike — From Scanner to Stealer: Inside the trivy-action Supply Chain Compromise
2. Aqua Security — Trivy security incident discussion
3. Wiz — Trivy compromised in TeamTNT/TeamPCP supply-chain attack
4. Snyk — Trivy GitHub Actions supply-chain compromise