Malicious Images on Docker Hub Accumulated Millions of Pulls in Coordinated Supply Chain Attack

Security researchers published findings this week documenting a coordinated campaign in which threat actors uploaded thousands of malicious container images to Docker Hub, the world’s largest public container registry. The images were designed to mimic legitimate base images for popular software stacks — Node.js, Python, Nginx, and several database engines — and contained embedded malware payloads that would execute during container initialization. At their peak, several of the malicious images had accumulated hundreds of thousands of pulls before Docker’s automated scanning and manual review processes flagged and removed them.

The campaign represents a maturation of supply chain attack techniques that have been applied to package managers like npm and PyPI for several years, now fully translated to the container ecosystem. It also highlights a fundamental trust problem that the industry has not fully resolved: when developers pull a container image to use as a base or dependency, they are trusting not just the code they can see but a complex chain of build processes, layers, and metadata that is difficult to verify at pull time.

How the Campaign Was Structured

The attacker accounts were created over a period of several months, with some registered as far back as eight months before the campaign’s active phase. This long lead time is a deliberate tactic: Docker Hub’s trust signals include account age and pull count history, and accounts that have existed for months without suspicious activity appear more credible to automated scoring systems. Some of the attacker accounts had even uploaded legitimate, benign images during the dormant period to build a positive track record.

The malicious images were uploaded with names that were carefully chosen to be plausible variations of official image names. Some used slight misspellings — “nginx-stable” instead of “nginx”, “python3-slim” instead of “python:3-slim” — while others used legitimate-looking namespace conventions that mimicked how organizations structure their private images. The images also included accurate, detailed README documentation pulled from the official repositories, which made them appear professionally maintained when viewed on Docker Hub’s web interface.

The malware payload itself was embedded at the image layer level, not in the Dockerfile instructions visible in the repository metadata. When a container based on the malicious image was started, an initialization script would execute that established a reverse connection to attacker-controlled infrastructure, harvested environment variables (which in containerized deployments frequently contain API keys, database credentials, and service account tokens), and attempted to enumerate the surrounding network from within the container’s perspective. In Kubernetes environments where pods have access to the cluster’s internal DNS, this enumeration could identify additional services to pivot to.

The Scale of Exposure

The researchers who documented the campaign analyzed Docker Hub’s public pull count data across the identified malicious images. The aggregate pull count across all malicious images in the campaign exceeded two million before removal. Pull count is an imperfect proxy for actual deployments — a single automated CI/CD pipeline can generate thousands of pulls from a single image — but even accounting for that inflation, the exposure was substantial.

A meaningful fraction of those pulls likely came from development and testing environments where the malware payload would have connected to attacker infrastructure but where the harvested credentials had limited production value. However, even a small percentage of pulls from production workloads — applications running in cloud environments with IAM roles, cluster service accounts, or injected secrets — would represent significant compromise. The credential harvesting focus of the malware suggests the attackers were interested in the upstream access those credentials provide rather than the specific container environment itself.

Docker’s automated scanning infrastructure uses a combination of static analysis, behavioral signals, and reputation scoring to identify malicious images. The campaign’s success in accumulating pulls before detection reflects the limits of static analysis against obfuscated initialization scripts and the challenge of detecting behavioral anomalies at pull time — the malware does not execute until the container is started, which is after the registry-level analysis window has closed. Only dynamic analysis in a sandboxed execution environment would reliably catch this class of attack, and running every pulled image in a live sandbox before delivery is not currently practical at Docker Hub’s scale.

Why Container Supply Chain Attacks Are Especially Dangerous

Container images occupy a uniquely privileged position in the modern software supply chain. Unlike a library dependency that contributes code to a specific function in an application, a base container image becomes the entire execution environment — the operating system utilities, the runtime, the file system layout. Malicious code embedded at the image layer level runs in the same process space as the application and has access to everything the container can access: its mounted secrets, its network connections, its environment variables, its service account tokens if running in Kubernetes.

This is architecturally different from a compromised npm package that might affect one function in one service. A compromised base image affects every service built on that image in its entirety. The blast radius is determined by how widely the image is used, not by how much code the attacker controlled in the dependency tree.

The problem is compounded by how container images are typically consumed. Developers rarely audit the full layer history of base images they pull. Many teams have informal policies about using official images or well-known namespaces, but few have formal verification processes that check image digests against a known-good state at pull time. Continuous integration pipelines that run nightly rebuilds or fresh pulls on each build create persistent exposure if a malicious image enters the pull cache.

Recommendations for Container Security

The most direct defense against this class of attack is to avoid pulling images from Docker Hub’s public namespace for production workloads. Organizations should maintain an internal container registry — Amazon ECR, Google Artifact Registry, Azure Container Registry, or a self-hosted Harbor instance — and import only explicitly approved images into that registry after scanning. Application workloads then pull exclusively from the internal registry, which the team controls and which does not reflect updates to upstream public images without an explicit approval step.

Image signing and verification via tools like Sigstore and cosign provide a cryptographic way to verify that a pulled image was built and signed by the expected party and has not been modified since signing. Docker Hub supports content trust via Docker’s Notary implementation, but adoption has been limited because the tooling friction is higher than simply pulling by tag. Enforcing digest-based pulls — using the SHA256 digest of the specific image layer rather than a mutable tag — prevents an attacker from swapping a malicious image behind an existing tag, though it does not help if the initial image pulled was already malicious.

Runtime security tools like Falco, Tetragon, or commercial equivalents can detect the behavioral indicators of this type of malware post-deployment — unexpected outbound network connections from containers, unexpected process execution chains, file access outside normal application paths. These tools do not prevent the initial compromise but can limit attacker dwell time by alerting on the malware’s characteristic behaviors during or immediately after initialization. In a Kubernetes environment with a mature runtime security posture, the reverse shell connection that is central to this malware’s design would generate an alert within seconds of the container starting.

Docker Hub has announced additional scanning enhancements and expanded use of automated behavioral analysis in response to this campaign. The platform has also increased scrutiny on newly created accounts uploading images with names that closely match official image namespaces. These changes will raise the cost of this specific attack pattern, but the history of package manager supply chain attacks suggests that adversaries adapt rather than abandon the technique. The fundamental defense remains organizational: treat the public container registry as an untrusted source and require an explicit approval process before any image enters your production environment.

Docker’s official guidance on supply chain security, image signing, and content trust is published at the Docker Security documentation. Organizations should review Docker’s content trust and signing features as part of hardening their container image pipeline against this class of attack.

Related coverage: CVE-2026-33626 SSRF in LMDeploy — another active threat targeting containerized AI infrastructure. Also: CISA Adds 8 Exploited CVEs to KEV — the vulnerability prioritization framework every security team needs.