Trivy Docker Images Hit by Fresh Supply Chain Attack

The Trivy incident just got bigger. After the initial compromise of version 0.69.4, researchers at Socket found that Docker images tagged 0.69.5 and 0.69.6 were also tainted, with 0.69.6 still pointing to a malicious image at the time of reporting.

That matters because Trivy is a scanner many teams drop straight into CI/CD pipelines to check containers, code, and dependencies. If the scanner itself is compromised, the trust chain breaks in a place developers usually treat as safe.

The new findings turn this from a single bad release into a wider supply chain incident. The attack now touches Docker Hub, GitHub Actions, and the release process around one of the most widely used open-source security tools in container workflows.

What changed after the first Trivy compromise

On March 19, 2026, attackers compromised Trivy 0.69.4 and injected credential-stealing malware into official releases and GitHub Actions. By March 22, researchers had identified two more malicious Docker image tags, 0.69.5 and 0.69.6, uploaded without matching GitHub releases.

That detail is important. A normal release flow leaves a paper trail: source tag, build, artifact, and published image. Here, the image tags appeared without the usual release process, which is exactly the kind of mismatch defenders should watch for in build pipelines.

Socket’s analysis said the new images carried indicators linked to the TeamPCP infostealer seen in the earlier part of the campaign. Aqua Security later confirmed it had found additional suspicious activity on March 22, including unauthorized changes and repository tampering.

• 0.69.3 is the last known clean Trivy release
• 0.69.4 was the first compromised version and has been removed
• 0.69.5 and 0.69.6 were later found compromised in Docker Hub
• The latest tag at the time pointed to 0.69.6
• Researchers found typosquatted C2 domains and exfiltration artifacts in the malicious binaries

Why CI/CD pipelines are the real target

This kind of attack works because developers trust the scanner as much as they trust the code it scans. When a tool like Trivy runs inside CI/CD, it often has access to source repositories, build logs, cloud credentials, and environment variables. A compromised scanner can quietly collect those secrets while looking like a routine security job.

Aqua Security said the activity matched the attacker’s earlier behavior. That phrasing fits the pattern: initial access through one channel, then reuse of tokens and automation to spread across related systems. In this case, the attackers moved from GitHub Actions into Docker distribution and then into internal repository exposure.

For teams that pin only a tag like trivy:latest or even a version tag without digest verification, that is a problem. Docker tags can be reassigned, and this incident is a clean example of why a tag is a pointer, not proof.

“Based on our current understanding, this activity is consistent with the attacker’s previously observed behavior,” Aqua Security said in its March 23 update.

That quote matters because it signals continuity, not a random one-off breach. The attacker reused the same operational style across multiple stages, which usually means defenders should expect more than one infected artifact before the campaign burns out.

The GitHub exposure made the blast radius wider

The attack did not stop at Docker images. Researchers reported that an internal GitHub organization tied to Aqua Security was briefly exposed, with dozens of repositories renamed and made public during the incident. Investigators believe a compromised service account token had access to multiple GitHub organizations.

The speed of the change is telling. The repository modifications reportedly happened in a scripted burst lasting about two minutes, which points to automation rather than a human clicking through pages one by one. That kind of burst usually means the attacker already had a playbook and a token with broad reach.

There is also a broader threat angle here. The campaign has been linked to TeamPCP, a group researchers say has moved beyond pure credential theft into worm propagation, ransomware deployment, cryptocurrency mining, and destructive activity against Kubernetes environments.

• Dozens of repositories were reportedly renamed and made public
• The exposure lasted roughly two minutes
• A service account token may have reached multiple GitHub organizations
• TeamPCP has been tied to credential theft, ransomware, mining, and destructive Kubernetes attacks

How this compares with other supply chain incidents

The Trivy case fits a pattern we have seen in other open-source compromises: one entry point, then rapid reuse across package registries, build systems, and developer tooling. The difference here is the tool itself is a security scanner, which raises the stakes for every pipeline that treats scan output as trustworthy by default.

We can compare the blast radius with a few recent supply chain events. The 2019 Docker Hub breach exposed about 190,000 users. The more recent Trivy incident did not expose that many accounts, but it reached into a more sensitive part of software delivery: the security checks that gate releases.

That makes verification more important than version numbers. Teams should compare what they pull against what was actually released, and they should prefer immutable digests over mutable tags whenever possible.

• Docker Hub tags can be changed after publication
• GitHub Actions can be abused to inject malicious build output
• Scanner tools can become attack vehicles inside CI/CD
• Digest pinning gives stronger integrity checks than version tags alone

Aqua Security said there is no indication its commercial products were impacted, including Trivy as delivered within the Aqua Platform. That narrows the confirmed damage, but it does not reduce the need for review if your pipelines pulled the affected open-source images directly.

What teams should do now

If your builds used Trivy recently, check whether your pipelines pulled 0.69.4, 0.69.5, or 0.69.6 from Docker Hub. Review scan jobs for odd outbound traffic, unknown environment variable access, unexpected repository changes, and any authentication activity tied to the scanner container.

Then lock down the basics. Pin images by digest, not by tag. Rotate any credentials that may have been available to CI jobs. Audit GitHub Actions permissions and service account tokens. If you depend on security tools inside automation, treat them like production software, because attackers do.

The practical prediction here is simple: more supply chain attacks will aim at the tools developers trust most, especially scanners, package managers, and CI helpers. The next incident will probably look less like a loud breach and more like a normal build job that quietly shipped a bad binary.

If your pipeline still trusts mutable tags, this is the week to fix that. The question is not whether another scanner will be targeted, but which one gets hit next.