Critical Security Flaws Found in 20% of Popular Docker Container Images

This article is based on research originally reported by SDxCentral, covering findings from Kenna Security principal security engineer Jerry Gamblin. Original publication date: July 2019.

The Scale of the Problem

A Kenna Security study scanning the top 1,000 images on Docker Hub found that a majority contained at least one notable security vulnerability. More concerning: one in five — roughly 20% — contained what the scoring methodology classified as a critical security flaw. Several of the most widely downloaded images, with more than 100 million pulls, were found to carry hundreds of open CVEs (Common Vulnerabilities and Exposures).

CVEs are standardized identifiers maintained by MITRE for known security vulnerabilities. Each CVE is typically assigned a CVSS (Common Vulnerability Scoring System) base score on a 0–10 scale:

• 0.0–3.9: Low severity
• 4.0–6.9: Medium severity
• 7.0–10.0: High severity

Gamblin’s analysis found that many of the top containers had at least one CVE rated high severity on the CVSS scale.

Kenna Risk Scoring Added Context

In addition to CVSS scores, Gamblin applied Kenna Security’s proprietary Kenna Risk Score, which correlates additional variables including exploitability and observed attacker activity to produce what the firm describes as a more operationally accurate risk rating. The Kenna scale runs from 0 to 1,000:

• 0–329: Low risk
• 330–659: Medium risk
• 660–1,000: High risk — should be immediately remediated

Applying this scoring to the top 1,000 Docker Hub images produced striking results:

• More than 60% of images scored at or above 330 (medium risk or higher)
• More than 20% scored above 660, placing them in the high-risk category

Abandoned and End-of-Life Images Are the Worst Offenders

Gamblin noted that the images carrying the highest number of vulnerabilities tended to be the oldest ones — images that appear to be abandoned or officially end-of-life (EOL). When a maintainer stops actively updating an image, security patches stop flowing in, and the CVE debt accumulates over time.

This is a pattern familiar to anyone managing software dependencies: unmaintained packages become liabilities. The Docker image ecosystem is no different. Pulling a popular image with tens of millions of downloads does not guarantee it is actively maintained or patched.

“If an organization is using a container with a large number of open, high-risk vulnerabilities, they should be concerned with patching the vulnerabilities, building their own container, or migrating to a better-maintained one.”

— Jerry Gamblin, Principal Security Engineer, Kenna Security

These Are Code Vulnerabilities, Not Docker Vulnerabilities

Rani Osnat, VP of Product Marketing at Aqua Security, made an important distinction when responding to the findings. The vulnerabilities found in these images are not flaws in Docker itself — they are flaws in the code that Docker runs inside containers. Docker is the runtime; the vulnerable packages are the contents.

“Known vulnerabilities in container images continue to be a key concern for anyone using containers, and they should be because they are the easiest thing for attackers to exploit.”

— Rani Osnat, VP Product Marketing, Aqua Security

Osnat emphasized that scanning for these vulnerabilities is both straightforward and highly recommended at multiple stages:

• During CI/CD pipeline builds (before images are pushed)
• In container registries (catching vulnerabilities before deployment)
• At runtime, using compensating controls when patches cannot be immediately applied

Runtime Controls That Reduce Exposure

When a patch is unavailable or impractical to apply immediately, Osnat recommended several runtime security controls to limit the blast radius of a vulnerable container:

• Vulnerability shielding: Blocks known exploit patterns at the network or system-call level without requiring a patch
• Drift prevention: Prevents new binaries or code from being injected into a running container after it has been deployed
• Behavioral whitelisting: Learns the expected behavior of a container at baseline and flags or blocks anomalous activity that may indicate exploitation

A Notable Docker Runtime Vulnerability: CVE-2018-15664

The research was published in the context of an independently discovered Docker security flaw. In May 2019, Aleksa Sarai, a senior software engineer at SUSE, disclosed CVE-2018-15664, a path-traversal vulnerability in the docker cp command.

The docker cp command copies files between a container’s filesystem and the host machine. The bug allowed an attacker with access to the Docker API to read or write arbitrary files on the host — a significant privilege escalation risk. Sarai submitted a patch upstream for code review after disclosure.

“As far as I’m aware there are no meaningful protections against this kind of attack (other than not allowing ‘docker cp’ on running containers).”

— Aleksa Sarai, Senior Software Engineer, SUSE

This flaw is distinct from the image-level CVEs in Gamblin’s research but illustrates a broader point: the container security surface spans both the runtime and the image contents.

Practical Recommendations for DevOps Teams

The findings reinforce several security hygiene practices that DevOps and platform engineering teams should have in place:

1. Vet the source of every base image. Prefer Docker Official Images or Verified Publisher images on Docker Hub. Understand the maintenance cadence before adopting an image.
2. Integrate image scanning into CI/CD. Tools such as Trivy, Grype, Snyk Container, and Aqua Trivy can scan images for known CVEs before they are pushed to a registry or deployed to a cluster.
3. Scan your registry continuously. New CVEs are published after images are built. Registry-level scanning (e.g., Docker Hub’s built-in scanning, Amazon ECR scanning, or Harbor with Trivy) catches vulnerabilities that emerge post-build.
4. Pin and regularly update base images. Avoid latest tags. Pin to a specific digest, and build a process to pull updated base images on a regular cadence.
5. Avoid abandoned images. If a Docker Hub image has not been updated in over a year and has open high-severity CVEs, consider building your own or switching to a maintained alternative.
6. Apply runtime controls. Implement Pod Security Admission (Kubernetes), seccomp profiles, AppArmor/SELinux policies, and read-only root filesystems to reduce the attack surface even when vulnerable packages are present.
7. Keep the Docker runtime patched. CVE-2018-15664 and similar runtime flaws are separate from image content vulnerabilities. Maintain your container runtime versions alongside your image hygiene practices.

The Bottom Line

Popularity is not a proxy for security. An image with 100 million pulls may still carry hundreds of unpatched CVEs — particularly if it has been abandoned by its maintainer. Organizations need to treat container image provenance and freshness with the same rigor applied to any other software dependency.

“Organizations should not assume that a container is secure because it’s hosted on Docker. Ultimately, the goal of this project is to shine a light on these containers and educate users on potential risks to drive better security practices.”

— Jerry Gamblin, Kenna Security

Container security is a shared responsibility: maintainers must keep images updated, and consumers must validate what they pull, scan what they build, and monitor what they run.