64% of Popular Docker Hub Images Contain Critical Flaws, Kaspersky Research Finds

Container security is in a worse state than most teams realize. A new study by Kaspersky researchers published May 29, 2026 on Securelist found that 64 out of 100 popular Docker Hub images — each with between 10,000 and over one million downloads — contained critically vulnerable software, while only 10% were fully up to date. With over 85% of container images in production carrying high or critical vulnerabilities industry-wide, and 37% of organizations reporting a container or Kubernetes security incident in 2024 alone, the findings confirm that the container ecosystem has a systemic patching and configuration problem that is being actively exploited right now.

// 01 Container Security: What Kaspersky Found in 100 Docker Images

Docker Hub is the world's largest public registry for container images — pre-built, layered software packages that encapsulate an application and its entire runtime environment, from the OS base layer up to the application code. Because teams pull these images directly into production pipelines, a single compromised or unpatched image can propagate vulnerabilities across thousands of deployments in minutes.

Kaspersky researchers Yaroslav Shmelev, Anton Kivva, Denis Parinov, Vladimir Kuskov, and Yanina Balandyuk-Opalinskaya analyzed 100 of these popular images using their KIRA AI assistant and Kaspersky Container Security (KCS) scanning platform. The results were stark across seven distinct vulnerability categories:

• Outdated and unpatched base images — the foundational OS layer had not been rebuilt against current security patches, leaving known CVEs baked in by default.
• Plaintext credential exposure via ENV directives — database passwords and API keys embedded directly in the image layer, recoverable from Docker history by anyone who can pull the image.
• Hardcoded default passwords — strings like changeMePlease shipped as the application's default credential, left unchanged by operators.
• Insecure sudo configuration (NOPASSWD: ALL) — a sudoers configuration granting any process running as a non-root user instant, passwordless root access with a single command.
• Excessive file permissions — chmod 777 applied to system paths, allowing any process to read, write, or execute sensitive files.
• Integrity verification gaps — software fetched over plain HTTP with certificate validation disabled, making the download trivially interceptable and replaceable with a malicious binary.
• Supply chain compromise via infected upstream images — malicious code injected into the image itself before it ever reached the operator.

The following dangerous Dockerfile patterns illustrate how categories two and four manifest in real images pulled daily by production systems:

# Anti-pattern 1: Credentials baked into the image layer via ENV
# These values are readable by anyone who runs: docker history <image>
FROM ubuntu:22.04
ENV DB_PASSWORD=changeMePlease
ENV API_SECRET=sk-prod-abc123xyzABC
ENV AWS_ACCESS_KEY_ID=AKIAIOSFODNN7EXAMPLE

# Anti-pattern 2: Passwordless sudo grants instant root to any process
RUN apt-get install -y sudo && 
    echo "appuser ALL=(ALL) NOPASSWD:ALL" >> /etc/sudoers
USER appuser
# Any attacker who reaches appuser can now run: sudo su -

Both patterns are invisible at runtime and require no vulnerability to exploit — they are intentional misconfigurations that survive image rebuilds unless explicitly remediated.

// 02 The CVEs Lurking Inside Production Containers

Outdated base images are not an abstract risk. The Kaspersky report identified a range of specific, high-severity CVEs embedded in popular images currently in active use.

CVE-2025-49844 is a remote code execution (RCE — the ability for an attacker to run arbitrary commands on a remote system without physical access) flaw in the Redis Lua parser. Redis is widely used as a cache layer and message broker inside containerized microservices, making this a high-value target in any cloud-native stack.

CVE-2026-24061 affects nginx, the near-ubiquitous reverse proxy and web server that fronts a large proportion of containerized web applications. The flaw enables a server crash or RCE specifically when ASLR (Address Space Layout Randomization — a memory protection mechanism that randomizes where system libraries are loaded in memory, making exploitation significantly harder) is disabled. Many container base images disable ASLR for performance, turning a mitigated flaw into a fully exploitable one.

CVE-2023-4911, nicknamed "Looney Tunables," is a local privilege escalation (the ability to move from a limited user account to full root/administrator access on the same system) flaw in glibc — the GNU C Library that underpins virtually every Linux-based container. Because containers share the host kernel, a process that escalates privileges inside the container is one step away from escaping it entirely.

CVE-2021-4034, known as "PwnKit," is a privilege escalation vulnerability in polkit (a system service for managing authorization on Linux). Despite being patched in 2022, it continues to appear in unpatched base images because teams rebuild containers infrequently. CVE-2025-55182, a flaw in React Server Components, was reported as being exploited in the wild within one day of public disclosure — demonstrating how fast the window between disclosure and active exploitation has shrunk for popular frameworks deployed in containers.

// 03 Container Escape and Privilege Escalation in the Wild

A container escape is a class of attack where a process running inside an isolated container breaks through the isolation boundary and gains access to the host operating system — effectively jumping from a sandboxed environment into full host control.

The Kaspersky research highlights two critical container escape CVEs identified in parallel research. CVE-2026-34040, dubbed "Leaky Vessels," exploits symlink race conditions in runC — the low-level container runtime that underpins Docker, Kubernetes, and most container orchestration platforms. An attacker with code execution inside a container can trigger the race condition to write files outside the container's filesystem namespace, gaining host access.

CVE-2026-31431, tracked as "Copy Fail," is a Linux kernel local privilege escalation flaw (covered in depth in our CVE-2026-31431 Linux privilege escalation detection guide) that has been observed in active container exploitation chains. Because all containers on a host share the same Linux kernel, any kernel-level privilege escalation achieved from within a container is effectively a host compromise.

Beyond CVE-based escapes, three misconfigurations create trivially exploitable paths to host access:

• The --privileged flag: running a container with --privileged disables all kernel isolation mechanisms and grants the container complete access to the host's devices and namespaces. It is the equivalent of running as root on the host with no sandboxing.
• Mounting the Docker socket (/var/run/docker.sock): the Docker socket is the Unix socket that the Docker daemon (the background service managing containers) listens on. Mounting it inside a container grants the container the ability to create new containers — trivially exploitable to launch a privileged container that mounts the host filesystem.
• Misconfigured Linux capabilities: instead of full --privileged, some images grant specific elevated capabilities (e.g., CAP_SYS_ADMIN, CAP_NET_ADMIN) that are individually sufficient to escape isolation when combined with a kernel vulnerability.

// 04 Malware Actively Targeting Containers

The Kaspersky findings are not theoretical — specific malware families are in active production use against containerized environments right now.

Kinsing is a cryptominer and botnet payload that explicitly targets container deployments. It has been observed exploiting CVE-2023-4911 ("Looney Tunables") to escalate from container-level access to host root, then deploying a persistent backdoor alongside the mining payload. Kinsing scans for exposed Docker APIs and misconfigured Kubernetes dashboards as its primary initial access vectors.

perfctl is a stealthy Linux malware that uses CVE-2021-4034 ("PwnKit") for privilege escalation and deploys a rootkit to hide its processes and network connections from standard system tools like ps, netstat, and ls. Its rootkit capability makes it particularly difficult to detect through standard container monitoring.

Dero miner is notable for its auto-propagation capability — once deployed inside one container or pod, it actively scans the internal network for adjacent vulnerable containers and spreads laterally without human operator involvement.

Mirai and Gafgyt variants — originally IoT botnets — have been adapted to target containerized Linux environments, exploiting weak credentials and exposed management APIs to conscript container hosts into DDoS (Distributed Denial of Service) botnets.

In March 2026, a supply chain incident compromised the Trivy security scanner and LiteLLM projects — a malicious file was injected directly into a container image distributed through official channels. This is precisely the trust model that makes container supply chain attacks so damaging: operators implicitly trust images from recognized projects, and a single compromised upstream image can reach thousands of production deployments before discovery. This pattern mirrors the attacks we covered in our SAP npm mini Shai-Hulud supply chain analysis and is consistent with the malicious package distribution techniques documented in the Hugging Face ClaWHub campaign.

// 05 Container Security: What You Should Do Right Now

• Automate image rebuilds on a fixed schedule. A container image that was clean when built in January is not clean in May. Set up a CI/CD pipeline trigger that rebuilds all base images weekly, or immediately on upstream CVE disclosure for the OS layer. Images that are not rebuilt are not patched — full stop.

• Remove all credentials from ENV directives and Dockerfile history immediately. Audit every Dockerfile in your organization with docker history --no-trunc <image> to surface any secrets baked into image layers. Migrate to Docker Secrets (for Swarm) or Kubernetes Secrets (for K8s) — both provide secrets as mounted files or environment variables injected at runtime, never baked into the image. The rule: if a secret appears in a Dockerfile, it is compromised.

• Enforce the principle of least privilege at every layer. Remove --privileged from all container run configurations unless there is a documented, audited reason. Audit /var/run/docker.sock mounts and remove them from any container that does not explicitly require them. Drop all Linux capabilities not required by the application using --cap-drop ALL and selectively add back only what is needed.

• Implement SHA256 digest pinning and HTTPS-only downloads. Replace any FROM image:latest references with FROM image@sha256:<digest> to ensure you are running exactly the image you verified — not whatever latest resolves to at build time. Replace all HTTP download URLs in RUN directives with HTTPS and never disable certificate validation (--no-check-certificate, -k, CURLOPT_SSL_VERIFYPEER=false are all red flags).

• Deploy runtime behavioral monitoring. Static scanning at build time catches known CVEs; it does not catch zero-days, novel malware, or post-deployment exploitation. Tools like Falco (open source), Sysdig, or Kaspersky Container Security provide kernel-level syscall monitoring that can detect privilege escalation attempts, unexpected outbound connections, and process anomalies in real time inside running containers.

• Scan public images before use and pin your dependencies. Never pull a public Docker Hub image into production without running it through a vulnerability scanner (Trivy, Grype, or equivalent) first. Pin all dependency versions — do not use floating tags. Review image change histories when upstream images update.

// 06 Background: Why Container Security Is So Hard to Get Right

Container security sits at the intersection of three historically separate security domains — application security, infrastructure security, and supply chain security — and teams that are expert in one are often weak in the others. The container model also creates a false sense of isolation: developers who understand that a container is not a virtual machine are relatively rare, and the default assumption that "it's containerized so it's isolated" persists.

The update problem is structural. Traditional servers are patched in place; containers are immutable — you rebuild rather than patch. This is a security feature when done correctly, but it means a team that does not have automated rebuild pipelines will accumulate CVE debt rapidly. The Kaspersky finding that only 10% of images are fully up to date reflects the reality that most teams rebuilt their images once and left them static.

The credential problem is cultural. ENV directives in Dockerfiles are convenient, and developers who learned container basics from tutorials written before secrets management was standard practice will repeat those patterns. The fact that Docker image history is not encrypted — docker history reveals every layer including ENV values — is not widely understood.

The supply chain problem is asymmetric. Kaspersky found 1,650 malicious images on public Docker Hub. For a defender, that means screening thousands of images; for an attacker, it means uploading one convincing image and waiting for it to accumulate downloads.

// 07 Conclusion

The Kaspersky research is a concrete, data-backed confirmation of what many security teams have suspected but lacked the evidence to act on: container security at scale is failing. With 64% of popular images carrying critical vulnerabilities, active malware explicitly designed for containerized environments, and supply chain attacks hitting trusted tools like Trivy and LiteLLM, the risk is real and present. The defensive path is not exotic — automated rebuilds, secrets management, least privilege, integrity checks, and runtime monitoring are all well-understood controls. The gap is implementation. Teams that have not yet audited their running container images for the patterns described above should treat that audit as urgent work, not a backlog item.

For teams building detection coverage, our CVE-2026-31431 Linux privilege escalation detection guide covers the specific syscall and audit log indicators for the kernel-level escalation techniques used in container escape chains.