A Trusted Security Tool Becomes Part of the Attack Chain

A recent compromise involving Trivy, the well-known open-source vulnerability scanner maintained by Aqua Security, shows how damaging a supply chain incident can become when it affects software that is deeply embedded in development and CI/CD workflows.

According to reporting by The Hacker News and Dutch coverage from Security.nl, attackers used stolen credentials to distribute trojanised Trivy releases through official channels. The last known clean version was 0.69.3, while versions 0.69.4, 0.69.5, and 0.69.6 were identified as malicious.

The compromised releases reportedly behaved as expected from a user perspective, but in the background they collected sensitive data and transmitted it back to the attackers. That combination of normal functionality and hidden theft is exactly what makes supply chain attacks so difficult to spot quickly.

Why the Impact Was So Severe

Trivy is not just another developer utility. It is often integrated into automated scanning pipelines, container workflows, build systems, and cloud-native environments. That means it can run in places where highly sensitive secrets are present by design.

Reporting on the incident indicates that the malware targeted a wide range of valuable data, including SSH keys, Kubernetes configuration files, cloud credentials, Docker registry credentials, CI/CD secrets, database logins, infrastructure-as-code secrets, API keys, and environment files. In practical terms, that gives an attacker many possible routes to move from one compromised build or workstation into broader infrastructure.

This is what makes the incident more than a simple malicious update. It became a bridge from software distribution compromise to infrastructure compromise.

From Infostealer to Worm and Kubernetes Wiper

One of the most concerning aspects of this case is how the campaign appears to have evolved. The attack reportedly did not end with credential theft. Stolen data was used to broaden access, compromise additional assets, and support further malicious activity across cloud-native environments.

The reporting describes follow-on activity that includes worm-like propagation and destructive behaviour against Kubernetes systems. That escalation matters. It shows how a compromise in a trusted scanning tool can quickly move beyond espionage or credential collection and become an operational threat capable of disrupting entire environments.

For defenders, this changes the response mindset. The question is not only whether a malicious binary was executed, but also whether the surrounding infrastructure, secrets, service accounts, and orchestration environments were exposed during that execution.

How to Check Whether You May Be Affected

If you use Trivy anywhere in your environment, start by checking which version is installed or executed in your pipelines. The command below will show the locally installed version:

trivy --version

If the output shows 0.69.4, 0.69.5, or 0.69.6, you should assume the system may have been exposed and investigate further.

If Trivy was used through Docker, review which container images are present:

docker images | grep -i trivy

You can also check whether any Trivy-based containers are or were present:

docker ps -a | grep -i trivy

Because exposed Docker APIs were mentioned as part of the broader attacker tradecraft, it is also wise to verify whether Docker is listening insecurely on port 2375:

ss -tulnp | grep 2375

If you run Kubernetes workloads, review recent activity for unexpected privileged deployments, new DaemonSets, or suspicious changes in system namespaces:

kubectl get daemonsets -A
kubectl get pods -A -o wide
kubectl get events -A --sort-by=.metadata.creationTimestamp | tail -50

For build servers and runners, it is also sensible to search logs and shell history for recent Trivy usage:

history | grep trivy
grep -R "trivy" /var/log 2>/dev/null | tail -50

What to Do If You Find Exposure

If any affected Trivy version was used, the safest assumption is that any secrets accessible to that environment may have been exposed. That means the response should go beyond removing the binary or replacing the container image.

Rotate credentials that may have been accessible, including cloud credentials, CI/CD tokens, registry logins, Kubernetes tokens, SSH keys, and API secrets. Review recent activity in your source code platform, runners, registries, cloud accounts, and cluster management systems for signs of misuse. If the affected system had broad access, treat the incident as a potential wider compromise instead of an isolated host issue.

Incidents like this also underline the importance of reducing the blast radius in advance. Long-lived tokens, overprivileged service accounts, and shared credentials between environments can turn a single leak into a systemic failure.

How BaseFortify Can Help

BaseFortify.eu helps organisations gain visibility into the real software and infrastructure components present across their environment. In a case like the Trivy compromise, that visibility matters because the first challenge is often understanding where the affected tool is installed, where it is executed, and which systems or pipelines may have been exposed as a result.

By mapping components and linking them to known vulnerabilities and threat context, BaseFortify helps security teams and administrators assess impact more quickly and prioritise remediation with more confidence. Instead of relying on scattered manual checks alone, teams can work from a clearer overview of potentially affected systems and their associated risk.