K8s Wiper & Worm Payloads Found in Trivy Docker Hub Images
Hey everyone,
Just reviewed the latest update on the Trivy compromise, and the situation on Docker Hub is nastier than we initially thought. While the GitHub Actions hijack got a lot of attention, the malicious artifacts pushed to Docker Hub (versions 0.69.4, 0.69.5, and 0.69.6) are carrying serious payloads.
Researchers confirmed these images weren't just cryptocurrency miners; they are dropping an infostealer, a worm, and specifically a Kubernetes wiper. The last known clean version remains 0.69.3. If your CI/CD pipelines are pulling latest or even a specific bad tag, you might be in trouble.
I recommend auditing your environments immediately. You can use a quick one-liner to check your local cache for the specific malicious tags:
docker images --format "{{.Repository}}:{{.Tag}}" | grep -E "trivy:(0.69.4|0.69.5|0.69.6)"
If that returns anything, purge the images immediately and ensure your runtime scanning is actually catching these behaviors, not just static vulnerabilities.
The inclusion of a K8s wiper in a supply chain attack is a significant escalation. It seems the attackers are actively targeting cloud-native infrastructure for disruption rather than just resource theft.
How is everyone handling image verification in their pipelines right now? Are you relying on digest pinning, or have you moved to building all scanning tools from source?
We're scrubbing all our dev environments right now. The irony of a security scanner spreading a wiper isn't lost on us. We've updated our deployment pipelines to explicitly pin the digest hash rather than the version tag to prevent this from happening again.
docker pull ghcr.io/aquasecurity/trivy@sha256:
It adds overhead to maintenance, but trusting tags is clearly dead.
From a SOC perspective, we're seeing the worm component attempt to propagate via the Docker socket. If you have /var/run/docker.sock mounted into your Trivy containers (common in CI runners), the malware can try to spawn other containers.
We've updated our Falco rules to alert on any unexpected process execution from the Trivy PID or socket access patterns that don't match the standard scan workflow.
This is exactly why we shifted to building our own golden images for scanning tools. It takes a bit longer to update versions, but we control the source and the build process. Pulling directly from a public registry for a security tool feels like a massive single point of failure now. Has anyone looked into the static analysis of those malicious layers yet to see exactly how the wiper triggers?
Verified Access Required
To maintain the integrity of our intelligence feeds, only verified partners and security professionals can post replies.
Request Access