How Hackers Break Into Docker Containers — 5 Real Attack Techniques (2026)

Docker container hacking techniques overlap significantly with cloud-native attack methodology — read Cloud Security Hacking 2026 for the AWS, Azure, and GCP layer that sits above containerised infrastructure. If you’re building a container security testing practice, the penetration testing methodology hub provides the broader framework. Understanding these five Docker attack techniques also prepares you for Kubernetes security testing, where many of the same misconfiguration classes appear at a cluster level with even wider blast radius.

Why Containers Are Not VMs — The Shared Kernel Attack Surface

The security model difference between virtual machines and containers is not a matter of degree — it is architectural. A virtual machine runs a complete guest operating system on top of a hypervisor that emulates hardware. The guest kernel talks to virtual devices. There is no legitimate path from the guest OS to the host kernel — any attempt to break out requires exploiting the hypervisor itself, which is a very small and heavily audited attack surface. Container isolation is built on a completely different model.

Containers share the host kernel. When a process inside a container makes a system call — opening a file, creating a socket, forking a process — it makes that call directly to the same kernel that the host uses. The isolation comes from Linux namespaces, which provide process, network, mount, and user isolation by giving the container its own view of those resources, and cgroups, which enforce resource limits. These are powerful isolation mechanisms when correctly configured. But they are not a hard security boundary in the same sense as a hypervisor.

The practical implication for security is this: every Docker container hacking technique exploits either a misconfiguration that gives the container excessive privileges (techniques 1, 2, and 4), a vulnerability in the container runtime itself that blurs the namespace boundary (technique 3), or a compromise of trust in the image layer before the container even starts (technique 5). In every case the ultimate target is the shared kernel — executing code on the host outside the container’s namespace.

Technique 1 — Privileged Container Escape

Privileged containers are the most prevalent container security misconfiguration I encounter. In a study of container deployments I have personally assessed across consulting engagements, approximately 40% had at least one container running with the --privileged flag. The flag is a blunt instrument — it disables every security control Docker applies to containers. Seccomp filters that restrict dangerous system calls: disabled. AppArmor or SELinux profiles that limit file access: disabled. Every Linux capability: granted. The container can see and interact with host devices directly.

The escape from a privileged container requires four commands and no CVEs. The container has access to the host disk as a device. You mount the host disk inside the container. You chroot into the mounted filesystem. You are now executing commands in the host’s root filesystem with host root privileges. Your container namespace is gone. You have full control of the host. The entire process takes under a minute and works on any Linux kernel version where the –privileged flag is available.

Technique 2 — Docker Socket Abuse

The Docker socket at /var/run/docker.sock is the Unix socket through which all Docker API commands pass. The Docker daemon that listens on this socket runs as root on the host. Any process that can communicate with this socket can issue Docker API commands — create containers, start containers, list running containers, mount volumes, modify network configuration. It has essentially the same power as root on the host.

This socket gets mounted inside containers most commonly in CI/CD pipelines. The pattern is logical-seeming: a Jenkins build agent, a GitLab runner, or a GitHub Actions runner needs to build Docker images as part of the CI process. The simplest way to give it that capability is to mount the Docker socket from the host. This works — the CI container can now run docker build. It also means that any code that runs in that CI pipeline has full control of the host. A malicious dependency, a compromised package, a miswritten build script — any of these can now create privileged containers, dump credentials, and modify the host filesystem.

The Docker socket exposure in CI/CD is an industry-wide problem. The solution is Docker-in-Docker using rootless Docker, Buildah, or Kaniko — tools that can build container images without requiring access to the host Docker daemon. These approaches are more complex to set up but eliminate the socket exposure entirely. For existing deployments where socket mounting cannot be immediately removed, a mitigation is to use an authorization plugin that restricts which Docker API operations the mounted socket can perform — though this adds complexity and is not a true fix.

Technique 3 — runc Container Runtime CVEs

The container runtime — the low-level software that actually creates and manages containers — has its own vulnerability history. runc is the standard container runtime used by Docker, containerd, and Kubernetes. CVE-2019-5736, disclosed in February 2019, was one of the most significant container security vulnerabilities ever found. It allowed a malicious container to overwrite the host’s runc binary by exploiting the way runc accesses its own executable via /proc/self/exe when exec-ing into a running container.

The attack worked as a race condition: while runc was in the process of exec-ing into the container, the container could open a writable file descriptor to the runc binary through the proc filesystem before runc sealed its own memory. By repeatedly opening and overwriting this fd, the container could replace the host runc binary with a malicious one. The next time any container on the host was started, the attacker’s binary executed as root on the host. This was not a Docker misconfiguration — it was a vulnerability in a fundamental component of the container stack, present regardless of how the container was configured.

Technique 4 — CAP_SYS_ADMIN and Namespace Escape

Linux capabilities divide root’s monolithic privilege set into approximately 38 distinct units. Docker drops most capabilities by default — containers get a reduced capability set that covers typical application needs without dangerous system-level access. The most dangerous capability from a container escape perspective is CAP_SYS_ADMIN, which grants a container the ability to perform system administration operations including mounting filesystems and manipulating namespaces. When this capability is granted to a container, the cgroup release_agent technique becomes available.

The cgroup release_agent technique, originally documented by security researcher Felix Wilhelm, works as follows: a container with CAP_SYS_ADMIN mounts a cgroup filesystem, creates a cgroup under it, sets the release_agent file to the path of a script on the host, and then causes a process in that cgroup to exit. When the last process in a cgroup exits, the release_agent is executed — but on the host, not inside the container. Because the release_agent is on the host filesystem and is executed by the kernel on behalf of cgroup cleanup, it runs with host-level privileges outside any container namespace.

Technique 5 — Container Image Supply Chain Compromise

The four techniques above require code execution inside a running container as a starting point. Supply chain compromise is different — it happens before the container ever runs. By poisoning the container image at any point in the build and distribution chain, an attacker gets their malicious code executed in every environment that pulls and runs that image, without needing to compromise any of those environments individually.

Supply chain attacks against container images have occurred at significant scale. The most common form is typosquatting — uploading malicious images to Docker Hub with names similar to popular official images (nginx vs ngnix, alpine vs alpline). These images contain hidden backdoors that phone home, mine cryptocurrency, or exfiltrate credentials from the environment they run in. A more sophisticated form is compromising the build pipeline that produces legitimate official images, as happened with several npm packages in the Node.js ecosystem that had Docker image counterparts. Understanding this threat requires thinking about the entire lifecycle of an image from its base layer through every RUN command in the Dockerfile to the final distribution tag.

Detection and Hardening — Closing All Five Docker Container Attack Paths

Every technique in this article has a specific mitigation. The good news about Docker container hacking is that the security controls are well-understood, the tooling to enforce them is mature and in many cases free, and implementing all five mitigations does not require significant application changes. The bad news is that “well-understood” does not mean “widely implemented.” Most container deployments I assess are missing several of these controls simultaneously.

The five core controls map directly to the five attack techniques: never use --privileged (closes technique 1), never mount the Docker socket in production containers (closes technique 2), keep container runtimes patched and monitored for CVE disclosure (closes technique 3), drop all capabilities and add back only specific ones required by the application (closes technique 4), scan images with Trivy in CI pipelines and pin to digest hashes (closes technique 5). Beyond these five, the deeper hardening layer includes: running containers as non-root users, using read-only root filesystems, enabling seccomp profiles for syscall filtering, and deploying Falco for runtime detection of escape attempts.