When was the last time you looked under the hood of the Docker container images you use? Because here’s the ugly truth: every FROM instruction, every copied binary, and every installed package that forms your container is a potential attack vector.
That means, if you're not regularly inspecting your container image layers and build-time dependencies, you're likely inheriting far more risk than you realize.
CVEs (Common Vulnerabilities and Exposures), insecure base images, hardcoded secrets, and excessive privileges are just a few of the ways attackers slip through. And this should be a concern for organizations like yours.
In fact, Red Hat’s 2024 State of Container Security report, which surveyed 600 DevOps, engineering, and security professionals, found that nearly half of teams (42%) admit container security keeps them up at night.
From container runtime vulnerabilities to CVEs that affect critical GPU workloads, this article breaks down nine of the most vital and commonly overlooked Docker container vulnerabilities.
What are Docker Container Vulnerabilities?
A Docker container vulnerability is any weakness, misconfiguration, or flaw within a container image, runtime, or its underlying infrastructure that attackers can exploit to compromise security. This includes both well-known CVEs and overlooked issues like insecure defaults, exposed secrets, or excessive privileges.
The speed and portability that make Docker containers so powerful for developers can also make them a nightmare for security teams. For example, pulling an image with the latest tag or running containers as root might seem harmless at first. But in practice, these are exactly the kinds of openings attackers look for.
A vulnerability, in plain terms, is anything in your container configuration that makes life easier for someone trying to break in.
With that in mind, let’s break down the nine most common and dangerous Docker container vulnerabilities you need to watch out for.
The Top 9 Vulnerabilities in Docker Containers
The following nine vulnerabilities are active CVEs and widespread misconfigurations observed across production environments. Each one represents a practical threat path that can lead to container compromise, host access, or lateral movement in your infrastructure.
Let’s break them down.
1. runC and Docker Container Breakout Vulnerabilities
RunC is a “low-level” container runtime mainly used by “high-level” container runtimes like Docker to spawn and run containers. Over the years, we’ve seen several runC and Docker container breakout vulnerabilities, which have resulted in attacks.
A major one, CVE-2019-5736, was discovered in February of 2019. This vulnerability enabled an attacker to exploit a runC deployment running Docker version before 18.09.2 by overwriting the host runC binary, thereby compromising host root access.
Though an old vulnerability (6 years old as of 2025), many teams are still exposed to it, especially in environments with unpatched or legacy Docker/runC versions, custom or forked runtimes, etc.
A critical nuance in the CVE-2019-5736 vulnerability is that it requires the container process to be running as a root user. Suppose containers were running as non-root containers (e.g., with USER 1000 in the Dockerfile or securityContext.runAsNonRoot: true in Kubernetes). In that case, attackers cannot trigger the overwrite path because they lack the necessary privileges, which is why it is important not to run your containers as the root user.
Since 2019, more runC and Docker container breakout vulnerabilities have surfaced, some with low severity and some critical:
- CVE-2024-21626: Container breakout through runC process.cwd & leaked fds
- CVE-2024-45310: Container breakout to create empty files or directories
- CVE-2024-23651: Buildkit mount cache race
- CVE-2024-23652: Buildkit build-time container teardown arbitrary delete
- CVE-2024-23653: Buildkit GRPC SecurityMode privilege check
Fixing these security vulnerabilities requires upgrading the affected Docker containers to a patched version.
NOTE: If you’re unsure of what version of runC you have in your environment, running docker version should yield the version as part of the output:
Severity: Low → Critical
2. CVE-2025-9074: Docker Desktop Unauthenticated Access to Docker Engine API From containers
The Docker Engine API provides a programmatic interface for interacting with the Docker daemon and managing Docker objects. It is present in all Docker tools, including Docker Desktop.
CVE-2025-9074 is a critical server-side request forgery (SSRF)-like vulnerability in Docker Desktop. With this vulnerability, containers can access the Docker Engine API via the configured Docker subnet at 192.168.65.7:2375 by default, even with “Enhanced Container Isolation” enabled. Also, with or without the "Expose daemon on tcp://localhost:2375 without TLS" option enabled.
The CVE-2025-9074 only affects macOS and Windows machines. While most production systems run on Linux, such as Docker, some do use Windows Server (especially if they require the use of Windows containers).
Attackers can exploit this CVE with just these three lines of Python code below:
import docker
client = docker.DockerClient(base_url="tcp://192.168.65.7:2375")
client.containers.run("alpine", "touch /mnt/exploit", volumes=["/Users/<username>/:/mnt"])The code above connects to the Docker daemon via TCP socket and runs a new Alpine container that creates a file exploit and mounts it to the host directory /Users/<username>. With that, when the container writes to the /mnt/exploit file, it writes to host /Users/<username>/exploit.
An attacker can modify the script to do anything the Docker engine can do, including controlling other containers, creating new ones, managing images, etc.
If you use Docker Desktop on macOS or Windows, make sure you update to the latest version, as this vulnerability has been fixed in version 4.44.3.
Severity: Critical
3. CVE-2022-0847: Dirty pipe (Linux Kernel Escape)
The CVE-2022-0847 Linux kernel vulnerability stems from a flaw in the pipe_buffer.flags logic of the kernel’s pipe code, which allows a malicious actor to write to read-only files, bypassing protections like O_RDONLY and immutable. Then, they can escalate their privileges.
While it’s not a container-specific vulnerability, it can be used from within an unprivileged Linux container to overwrite binaries like /usr/bin/sudo on the host, inject backdoors, and can be used for chaining exploits.
The only known fix for this vulnerability is to upgrade your Linux hosts to patched Kernel versions.
Severity: High
4. Insecure Base Images
Base images are the foundation of every container you build, and if they're vulnerable, so is your application. Unfortunately, when creating containers, many teams still use image tags like ubuntu:latest or node:alpine without realizing that these tags are moving targets.
The latest image your container uses today might be different from the one it uses tomorrow. This can introduce unexpected security vulnerabilities.
To mitigate this vulnerability, point to specific, trusted versions (e.g., FROM debian:bullseye-20230912) instead of using tags like latest. And while you use trusted versions of a particular image, remember to consistently scan using tools like Aikido security to detect CVEs and AutoFix vulnerabilities.
You should also scan images in your container registry to fix vulnerabilities before they make their way into your environment. Aikido can also integrate and scan images in your container registry, whether it be Docker Hub or Harbor.
Severity: Low → Critical (Depending on the container images and usage)
5. Unrestricted Docker Socket Access
Mounting the Docker socket, usually located at (/var/run/docker.sock) into a container, is one of the most dangerous misconfigurations in containerized environments. Doing this grants the container full access to the Docker Engine API, enabling it to control the entire host. Which isn’t inherently bad; however, a single malicious container could mean an attacker now has control of your entire host.
Teams sometimes mount the Docker socket to allow "Docker-in-Docker" builds or monitoring tools to manage containers, but it’s almost always a dangerous shortcut.
To mitigate this vulnerability, you should never mount the Docker socket into containers. If you require Docker-in-Docker functionality, it should be isolated in tightly controlled build environments using rootless Docker, gVisor, or Kata Containers.
If you use Kubernetes, you should enforce Pod Security Standards or admission policies to block containers from accessing host-level resources like the Docker socket.
Severity: Critical
6. CVE-2025-23266: NVIDIA AI Vulnerability (GPU Access Flaw)
AI and ML are all we’ve talked about in the past year. This is because it has changed how we work and live in general.
CVE-2025-23266 is a container‑escape vulnerability that affects the NVIDIA Container Toolkit and GPU Operator, which enables us to build and run GPU-accelerated containers.
The NVIDIA Container Toolkit uses OCI (Open Container Initiative) hooks (custom script or binaries) to configure containers for GPU access. One of these hooks, enable-cuda-compat, inherits environment variables from the container. This opens the door for an attacker to craft a malicious image that sets LD_PRELOAD to reference a rogue shared library.
When the privileged hook executes, the library is loaded on the host, outside the container's sandbox, effectively granting the attacker root access on the node.
In multi-tenant GPU clusters, this creates a serious risk of cross-tenant data leakage and node compromise.
NVIDIA has released patched versions of both components. Upgrading to Toolkit v1.17.8 and GPU Operator 25.3.1 or disabling an optional hook mitigates the vulnerability.
Severity: Important
7. Exposed Secrets
The 2025 IBM Cost of a Data Breach Report reveals that data breaches caused by compromised credentials took the longest to identify and contain. With the average cost of a data breach being $4.4M, organizations cannot afford to have exposed secrets.
Yet, they are still one of the most common mistakes developers make. These secrets include sensitive credentials such as API keys, passwords, encryption keys, private keys, and more, which could allow attackers to access or steal confidential data.
Developers can leak secrets in Docker containers via:
- Dockerfiles (ENV or ARG instructions)
- .env files copied into image layers, etc.
The scary part is that even after a container is deleted, if the image is still present (or pushed to a registry), the secrets may remain accessible.
The chances that your organization has leaked secrets is high. But what can you do about it right now?
Well you can and should:
- Find any active secrets and then
- Prevent any new one from reaching production.
There are also some solutions that provide a live secret detection feature that can help you assess exposed secrets potential risks.
Severity: High
8. Container Privileges Vulnerabilities
As mentioned earlier, you should not run containers as root users. While this doesn’t automatically give access to the host, as you’ve seen, it significantly increases the risk of breakout when combined with other vulnerabilities like CVE-2022-0492 or misconfigurations in volume mounts and capabilities.
Beyond running containers as root users, there are other ways a container can be vulnerable via privileges. This is particularly true when using a container orchestrator like Kubernetes, which automatically creates, modifies, and deletes containers.
With CVE-2023-2640 and CVE-2023-32629, an attacker can use a non-root privileged container with volume mount to escalate privileges.
In Kubernetes, you’d use Security Context to define privilege and access control settings for a container.
containers:
- name: app
image: myapp: latest
securityContext:
runAsNonRoot: true
runAsUser: 1000
allowPrivilegeEscalation: false
capabilities:
drop:
- ALLIn the above Security Context:
- runAsNonRoot: true: Ensures container won’t start as UID 0
- runAsUser: 1000: Explicitly runs the container as a non-root user
- allowPrivilegeEscalation: false: Blocks setuid or other escalation
- capabilities.drop: [ALL]: Removes all Linux capabilities by default
Managing container privileges and access requires understanding how your application behaves. For example, if you do not make any writes to disk, then you should mount any associated volumes as read-only, further reducing the attack surface.
Read our guide on container privilege escalation vulnerabilities and how to protect against them.
Severity: High → Critical
9. gh0stEdit: Layer-Based Access Vulnerability
Docker images are designed to ensure that their end users can clearly assess and see the content of an image before running it.
But in the case of gh0stEdit, that visibility doesn’t matter.
Although not a formal CVE, gh0stEdit (name given by its researchers) describes a novel vulnerability where an attacker can manipulate Docker images (even signed with Docker Content Trust) without breaking the image signature or detection by static/dynamic scans.
Figure 1: Docker Image Integrity Bypass: Layers Changed, Manifest Unchanged. Source (Hackernoon)
This manipulation is possible because Docker focuses on the manifest (the recipe that lists image layers and their digests), and not on every single file inside each layer.
If an attacker injects a malicious script into a layer, the container runs, bypassing the Dockerfile, build process, and registry checks. It can spread silently through your entire system.
Fixing and defending against gh0stEdit involves several steps, including:
- Always rebuilding container images from trusted sources
- Signing and verification of container images with tools like cosign
- Vulnerability and content scanning with tools like Aikido complements open-source scanners with custom rules, bridging gaps and revealing security flaws.
- Using an admission controller to prevent unsigned or unscanned images from running inside your cluster.
Severity: Low → Critical (Depending on the container images and attack surface)
Building a Resilient Docker Security Posture
As we explored in this article, vulnerabilities like runC container breakouts, unscanned base images, exposed secrets, and excessive privileges can quietly undermine your entire environment.
Implementing a resilient Docker security posture means moving beyond checkbox scans toward contextual, runtime-aware, policy-driven defenses that find and fix vulnerabilities automatically.
At Aikido, we love established open-source projects like Trivy, Syft, and Grype. But we also know from experience that using them in isolation isn’t a particularly good developer experience.
Aikido enhances these projects with custom rules to bridge gaps and reveal security flaws you wouldn’t be able to find otherwise. Unlike chaining various open-source tools together, Aikido frees you from having to build a scanning script or create a custom job in your CI/CD.
There is always more to learn about Docker security. To answer more of your questions on keeping Docker secure, check out our no-BS Docker security checklist for the vulnerability-minded developer.
.avif)
