Security researchers scanning the public Docker Hub registry have repeatedly landed on the same uncomfortable number: somewhere between 2.5% and 3% of publicly listed container images carry some form of malicious payload. Applied to a registry that hosts more than 15 million repositories and serves north of 6 billion image pulls a month, that percentage translates into hundreds of thousands of poisoned images sitting in plain sight — many of them still being pulled into production pipelines today. The most cited analysis, published by JFrog's security research team after crawling roughly 4.8 million public Docker Hub images, found tens of thousands of images containing cryptominers, embedded malware, or credential-harvesting scripts disguised as ordinary base images and utility containers.
That research wasn't a one-off. Follow-on work from Sysdig, Unit 42, and independent researchers publishing through Docker Hub's own abuse-reporting channel has kept surfacing the same pattern year after year: threat actors treat Docker Hub less like a software registry and more like a free, high-trust malware CDN. For a security team evaluating its software supply chain, the Docker Hub malicious images problem isn't a historical footnote — it's an active, ongoing exposure that shows up in dependency trees, CI base images, and Kubernetes manifests without anyone noticing.
The Scale of the Problem
The numbers are worth sitting with. JFrog's crawl of Docker Hub's public namespace grouped the ~4.8 million images it analyzed into three buckets: images with no clear indication of malicious intent, images that were "unsafe" due to exploitable misconfigurations or known-vulnerable software, and images that were outright malicious. That last bucket alone accounted for roughly 3% of the total — meaning well over 100,000 images were purpose-built to do something harmful to the systems that ran them.
Separately, cloud threat reports from Sysdig and others have tracked cryptojacking campaigns that specifically target exposed Docker daemons and misconfigured Kubernetes API servers, using Docker Hub as the distribution point for the mining payload itself. One well-documented campaign, tracked under names like "Kinsing" and various TeamTNT successors, has persisted for years precisely because new Docker Hub accounts and repositories are trivial to spin up faster than they can be reported and taken down.
The takeaway for defenders: this isn't a small, contained cluster of bad actors. It's a persistent, self-renewing ecosystem of malicious publishing that scales with the registry itself.
How Malicious Images Get In
Three techniques show up again and again across the research:
Typosquatting and impersonation. Attackers publish images with names deliberately close to popular ones — a hyphen swapped, a common misspelling, a plausible-sounding vendor prefix — so that a developer running a quick docker pull or an automated pipeline referencing an unpinned tag grabs the wrong image. Because Docker Hub's official/verified badge system only covers a small slice of the catalog, the visual cues developers rely on to distinguish "safe" from "unknown" are easy to fake or simply absent.
Poisoned base images. Rather than publish an obviously suspicious tool, some actors take a legitimate open-source base image, add a malicious layer or entrypoint script, and republish it under a similar name. Anyone building on top of that image inherits the payload silently, and it often survives multiple layers of downstream FROM statements before anyone inspects the actual filesystem diff.
Delayed or conditional payloads. A growing share of malicious images don't do anything harmful at build time or even at first run. Instead, an entrypoint script fetches a second-stage payload from an external server after the container is already deployed — a technique that defeats static image scanning performed only at the registry or CI stage, since the malicious behavior doesn't exist in the image until it's already running in someone's environment.
What's Actually Inside These Images
The payload categories are fairly consistent across reporting periods:
- Cryptominers remain the single most common find — XMRig and its variants show up repeatedly, usually configured to throttle CPU usage just enough to avoid triggering obvious performance alerts.
- Credential and secret harvesters scan environment variables, mounted volumes, and cloud metadata endpoints (like AWS's 169.254.169.254) for tokens and keys, then exfiltrate them to attacker-controlled infrastructure.
- Reverse shells and backdoors are baked into entrypoint scripts, giving an attacker persistent remote access to any host that runs the image.
- Malicious dependency chains — images that pull in compromised npm, PyPI, or RubyGems packages during the build step, effectively laundering a software-supply-chain attack through a container layer where it's harder to spot with source-code-focused tooling.
What makes this list particularly dangerous is that none of it requires the victim to do anything unusual. Pulling a public image and running it is the normal, everyday workflow for millions of developers — which is exactly why the attack surface is so attractive.
Why This Keeps Happening
Docker Hub's model is built for openness: anyone can create an account and publish an image with minimal friction, which is precisely what has made the container ecosystem grow as fast as it has. But that same openness means the registry's automated scanning — helpful as it is for known-CVE detection in well-formed images — was never designed to catch intentionally obfuscated, behaviorally-triggered malware published by someone who knows exactly how to evade it.
Compounding this, most organizations still treat "pull from Docker Hub" as an implicitly trusted action inside their CI/CD pipelines. Base images get referenced by a floating tag (node:latest, python:3-slim) rather than a pinned, verified digest. Few teams generate or ingest a Software Bill of Materials (SBOM) for third-party images before they hit a build pipeline, and fewer still track which of their running containers descend from an image that has since been flagged, deprecated, or reported for abuse.
What Security and Platform Teams Should Actually Do
Based on the pattern across these reports, a handful of concrete controls make the biggest difference:
- Pin images by digest, not tag, and treat any unpinned
FROMline in a Dockerfile as a build-time policy violation. - Generate or ingest an SBOM for every image before it's promoted past a dev environment, so that what's actually inside a container — down to transitive OS packages and language dependencies — is known and queryable, not assumed.
- Prefer verified publishers and minimal, purpose-built base images over broad community images with unclear maintenance histories.
- Monitor runtime behavior, not just build-time scans, since second-stage payloads and delayed execution are specifically designed to slip past registry and CI scanning.
- Prioritize remediation by actual exploitability, not raw CVE count — most container vulnerability backlogs are dominated by findings that are never reachable from running code, which buries the handful of genuinely dangerous images under noise.
How Safeguard Helps
This is exactly the gap Safeguard is built to close. Safeguard's reachability analysis goes beyond registry-level CVE matching to determine whether a vulnerable or suspicious package inside a container image is actually invoked by your application's code paths, cutting through the noise that makes teams numb to yet another "critical" finding in a base image. Griffin, Safeguard's AI-powered analysis engine, correlates image provenance, layer history, and behavioral indicators to flag images that resemble known malicious patterns — typosquatted names, unexpected entrypoint scripts, delayed-payload behavior — before they're pulled into a build. Safeguard also generates and ingests SBOMs automatically across your container fleet, giving teams a continuously updated, queryable inventory of exactly what's running in every image, including transitive dependencies buried three or four layers deep. When a genuine issue is confirmed, Safeguard can open an auto-fix pull request that swaps a compromised or unpinned base image reference for a verified, digest-pinned alternative, turning what used to be a multi-day incident response scramble into a reviewable code change. For teams pulling from Docker Hub and other public registries at scale, that combination — reachability-aware triage, AI-driven image analysis, live SBOM visibility, and automated remediation — is what turns "we hope our base images are clean" into something you can actually verify.