Trivy Supply Chain Attack: Malicious Docker Hub Images Identified

Overview of the Trivy Supply Chain Attack

A sophisticated Supply Chain Attack has targeted the widely used container security scanner, Trivy, via its official distribution channel on Docker Hub. Security researchers have identified that malicious actors gained unauthorized access to the Trivy repository, injecting malicious code into several recent image tags. According to The Hacker News, the breach resulted in the distribution of an infostealer, a self-propagating worm, and a destructive Kubernetes wiper.

The compromise affects Trivy container image versions 0.69.4, 0.69.5, and 0.69.6. While Docker Hub has since removed these specific tags, the window of availability was sufficient for the malicious images to be pulled into numerous automated CI/CD pipelines and local developer environments. The last verified clean version of the image is 0.69.3.

Technical Analysis: From Infostealer to Kubernetes Wiper

The attack vector utilized in this campaign is particularly dangerous because it leverages the trust associated with a security tool. When a developer or automated script executes a malicious Trivy image, the container initiates several concurrent TTP stages. Initially, the container executes an infostealer payload designed to harvest environment variables, cloud provider credentials (such as AWS IAM roles or Azure Service Principals), and Kubernetes Service Account tokens. This data is then exfiltrated to an attacker-controlled C2 server.

Analyzing malicious Trivy container image 0.69.5 payloads

One of the most concerning aspects of this campaign is the inclusion of a destructive component. When analyzing malicious Trivy container image 0.69.5, researchers discovered a script specifically designed to target the Kubernetes API. If the container is running with sufficient privileges—often the case for security scanners intended to audit cluster resources—it attempts to enumerate and delete all namespaces, deployments, and stateful sets. This behavior classifies the malware as a wiper, aimed at causing maximum operational disruption rather than just data theft.

Furthermore, the campaign features a worm-like capability. The malicious code scans the local network for reachable Docker sockets or container registries. If an unprotected socket is found, the malware attempts to perform an RCE by launching new malicious containers or overwriting existing images in the local registry. This facilitates Lateral Movement within the internal network, potentially allowing the threat to persist even after the initial entry point is closed.

Kubernetes wiper malware detection and Defense

Detecting this compromise requires a multi-layered approach. Because the malicious code resides within a trusted image name, standard image name filtering is insufficient. Organizations should implement Kubernetes wiper malware detection by monitoring for unusual API delete requests originating from pods associated with security scanning tools.

Security teams should also search for specific IoC signatures, such as outbound connections to unknown IP addresses on non-standard ports or the presence of unexpected shell scripts within /tmp or /var/run inside the Trivy container. Correlating logs in a SIEM or an EDR solution can help identify if a Trivy Docker Hub supply chain attack has impacted the environment. Analysts should map observed behaviors against the MITRE ATT&CK framework, specifically looking for techniques related to Software Supply Chain Compromise (T1195.002) and Data Destruction (T1485).

Mitigation and Remediation Steps

Immediate action is required for any organization that has pulled Trivy images in the last 48 hours. The following steps are recommended:

• Audit and Rollback: Identify all instances where Trivy versions 0.69.4, 0.69.5, or 0.69.6 were used. Roll back to version 0.69.3 immediately and purge any cached malicious images from local and private registries.
• Credential Rotation: Treat all secrets, tokens, and keys handled by affected CI/CD pipelines as compromised. Rotate AWS/Azure/GCP credentials and Kubernetes Service Account tokens.
• Pipeline Hardening: Implement image pinning using SHA256 hashes rather than tags to ensure only verified, immutable image versions are deployed in the future.
• Least Privilege: Ensure that security scanners like Trivy run with the minimum required Kubernetes permissions, ideally in a read-only capacity, to prevent wipers from performing destructive actions.