AquaSecurity's Trivy Supply Chain Compromise Incident Response Guide

Origin

The Trivy source code was compromised via a vulnerable GitHub Action. Attackers exploited this vulnerability to exfiltrate high-privilege secrets, enabling a large-scale supply chain attack. Notably, this specific GitHub Action vulnerability had been identified months earlier by the poutine CI/CD security scanner but remained unpatched.

Affected Versions and Exposure Window

Use the table below to determine if you used a compromised version of Trivy.

Component	Affected Versions	NOT Affected	Exposure Window (UTC)
trivy (binary)	v0.69.4 (including `latest` tag). GHCR, ECR Public, Docker Hub, deb, rpm, get.trivy.dev	1) v0.69.3 or earlier 2) Images referenced by digest	2026-03-19 18:22 – 21:42
trivy (Docker Hub)	v0.69.5–v0.69.6 (including `latest` tag)	1) v0.69.3 or earlier 2) Images referenced by digest	2026-03-22 15:43 – 01:40
trivy (Source)	Source code v0.69.4 or `latest` tag	SHA-pinned references	2026-03-19 17:43 – 23:13
trivy-action	1) All tags prior to 0.35.0 2) `version: latest` requested during exposure	1) @v0.35.0 2) SHA-pinned (since 2025-04-09)	2026-03-19 17:43 – 2026-03-20 05:40
setup-trivy	All releases	SHA-pinned references	2026-03-19 17:43 – 21:44

[!NOTE]

The Homebrew version of Trivy was not compromised.

For cloud environments, identify which CI pipelines used affected versions and check your platform logs for executions during the exposure windows listed above.

Impact Analysis

The impact depends on where the compromised version was executed. All affected versions used the TeamPCP Cloud Stealer, which identifies secrets in the session, encrypts them, and exfiltrates them to a Command & Control (C2) server.

1. Execution in Cloud CI (GitHub Actions)

If Trivy ran via trivy-action, setup-trivy or trivy, consider all secrets (${{ secrets.X }}) accessible to that workflow as compromised.

Exfiltration: If the primary C2 upload fails, the payload attempts to push stolen data to a public repository named tpcp-docs using the available INPUT_GITHUB_PAT.
OIDC/Ephemeral Secrets: There is currently no evidence that the payload utilized ephemeral secrets (OIDC, GITHUB_TOKEN). If your environment is properly configured, these short-lived tokens may have expired before the attackers could use them.

2. Execution on Local Devices (Servers, Dev Machines)

On local Linux systems, the malware attempts to establish persistence:

Persistence: It creates a Python script at ~/.config/systemd/user/sysmon.py and adds a corresponding systemd unit.
Remote Access: The C2 can trigger arbitrary code execution through this script, allowing for a complete manual takeover of the device.

Response Plan

If you confirm that a compromised version was executed:

Rotate Secrets: Immediately rotate all long-lived secrets (PATs, AWS keys, etc.) that were available in the environment during the run.
Remove Persistence: On local machines, audit and delete sysmon.py and any unauthorized systemd units.
Audit Logs: Start an in-depth investigation. On GitHub, review the Audit Log (Settings -> Archive -> Logs -> Audit log). Look for the hashed_token property to identify specific interactions associated with a compromised credential.

Hardening

To prevent similar supply chain attacks in the future:

Pin by SHA: Instead of using tags (like @v1 or @latest), pin GitHub Actions and container images by their immutable SHA-256 digest. If using binary in automated script, validating integrity is always an option.
Use Scanning Tools: Use poutine to identify vulnerable workflows including unpinned actions. Use bagel on local devices to assess which secrets are accessible to unprivileged programs.
Least Privilege: Split workflows into multiple jobs. Ensure each job has access to only the minimal secrets required.
Short-lived Credentials: Prioritize ephemeral secrets (e.g. OIDC) over long-lived secrets. While an attacker can still steal a live ephemeral token, the narrow window of validity significantly limits the damage.