Hackers hijacked Trivy GitHub Actions to steal CI/CD secrets


Organizations that used compromised Trivy components on March 19 and March 20, 2026 should treat their CI/CD secrets as exposed and rotate them immediately. Aqua Security says attackers used compromised credentials to publish a malicious Trivy v0.69.4 release, force-push 76 of 77 trivy-action tags to malicious commits, and replace all 7 setup-trivy tags.

This attack matters because Trivy is a widely used security scanner inside GitHub Actions pipelines. Instead of shipping a suspicious new branch or obvious fake release for the action, the attacker rewired trusted version tags that many teams were already using, which meant existing workflows could keep running while pulling malicious code.

Aqua says the March 19 breach was not a brand-new entry point. It was a continuation of the earlier Trivy incident disclosed on March 1, after secret rotation failed to fully cut off the attacker’s access. Aqua later said it had locked down automated actions and tokens more aggressively and removed malicious artifacts from affected channels.

What happened

According to Aqua’s advisory, the incident affected three pieces of the Trivy ecosystem. The malicious trivy-action code ran before the legitimate scan, harvested secrets from runners and filesystems, encrypted the stolen data, and then exfiltrated it. If the first exfiltration path failed, the malware could abuse the victim’s GitHub token to create a public repository named tpcp-docs and upload the stolen data there.

Aqua also published the exposure windows. The malicious trivy binary release v0.69.4 was live for about three hours, setup-trivy was affected for about four hours, and trivy-action remained compromised for roughly twelve hours. Teams that used mutable version tags during those windows may have pulled poisoned code without noticing, because the legitimate Trivy workflow still ran afterward.

Screenshot of the Socket package page for of the compromised tags (Source: Socket)
ComponentAffected versionsKnown-safe versionExposure window
trivy binary/imagev0.69.4v0.69.3 or earlierMarch 19, 2026, about 18:22 UTC to 21:42 UTC
aquasecurity/trivy-actionAll tags before 0.35.00.35.0 or SHA pin 57a97c7March 19, 2026, about 17:43 UTC to March 20, 2026, about 05:40 UTC
aquasecurity/setup-trivyAll releases before remediation0.2.6 or SHA pin 3fb12ecMarch 19, 2026, about 17:43 UTC to 21:44 UTC

Source: Aqua Security advisory and incident discussion.

How the attack worked

The attacker did not rely on a noisy new release for trivy-action. Aqua and outside researchers say the threat actor force-pushed existing tags so workflows that referenced versions such as @0.33.0 or @0.18.0 could quietly resolve to new malicious commits. Aqua says only @0.35.0 stayed untouched because it already pointed to the base commit used in the attack chain.

The stolen data set was broad. Aqua says the malware targeted runner memory plus more than 50 filesystem paths, hunting for SSH keys, Git credentials, cloud credentials, Kubernetes tokens, Docker configs, .env files, database secrets, and cryptocurrency wallet data. Aqua also said the payload used AES-256-CBC and RSA-4096 hybrid encryption before exfiltration.

Attack flow:

  • Force-push trusted action tags to malicious commits
  • Run a hidden infostealer before the real Trivy scan
  • Dump runner memory and search the filesystem for secrets
  • Encrypt the collected data
  • Send it to attacker infrastructure or, if that fails, upload it through a victim-controlled GitHub repository named tpcp-docs

What security teams should do now

Aqua’s guidance is direct. Move to known-safe versions, pin to full commit SHAs where possible, rotate every secret that may have been visible to affected runners, and search GitHub organizations for unexpected tpcp-docs repositories. Aqua also recommends blocking the command-and-control domain scan[.]aquasecurtiy[.]org and IP 45.148.10.212 at the network perimeter.

The remediation advice goes beyond cloud tokens. NHS England’s cyber alert says any pipeline that executed an affected action after the compromise window should be treated as fully compromised, and self-hosted runners need extra attention because additional credentials stored on disk may also have been exposed.

Immediate response checklist:

  • Upgrade trivy-action to 0.35.0 or pin 57a97c7
  • Upgrade setup-trivy to 0.2.6 or pin 3fb12ec
  • Avoid trivy v0.69.4
  • Rotate GitHub, cloud, registry, database, and SSH credentials
  • Review workflow logs from March 19 to March 20, 2026
  • Check for unauthorized public repositories named tpcp-docs
  • Isolate and review self-hosted runners that executed affected workflows

Why this incident stands out

This breach shows why version tags alone are not enough protection in CI/CD. Aqua’s own post says many pipelines trusted mutable tags, which let poisoned references spread without obvious changes in daily workflow behavior. GitHub SHA pinning did hold up here, and Aqua explicitly says SHA-pinned references were not affected.

Trivy Notification (Source: Socket)

It also shows how incomplete secret rotation can leave a door open. Aqua’s root-cause summary says the first March incident led to credential rotation, but not in an atomic way, which may have allowed the attacker to retain or regain valid access and return on March 19.

FAQ

Was Trivy itself compromised, or only the GitHub Action?

Both were affected. Aqua says the incident included the malicious trivy v0.69.4 release, compromised trivy-action tags, and malicious setup-trivy tags.

Is [email protected] safe to use?

Yes. Aqua says @0.35.0 was the unaffected trivy-action tag, and it published the safe SHA 57a97c7 for teams that want a pinned reference.

Were SHA-pinned GitHub Actions affected?

Aqua says SHA-pinned references were not affected. The problem mainly hit workflows that trusted mutable version tags.

What if my pipeline ran an affected version during the exposure window?

Treat all secrets available to that runner as compromised, rotate them immediately, and investigate for exfiltration signs, including any unexpected tpcp-docs repositories.

What about self-hosted runners?

They may face greater risk because the malware searched the filesystem for sensitive files in addition to runner memory. NHS England says extra credentials stored on self-hosted systems should also be reset.

Readers help support VPNCentral. We may get a commission if you buy through our links. Tooltip Icon

Read our disclosure page to find out how can you help VPNCentral sustain the editorial team Read more

User forum

0 messages