criticalInfrastructure

Docker Socket Exposed to Containers

What Is This Vulnerability?

Mounting the Docker socket (/var/run/docker.sock) inside a container gives that container full control over the Docker daemon on the host. This effectively grants root access to the host machine because the container can create new privileged containers, access the host filesystem, and execute arbitrary commands outside its own namespace.

Why It Happens

Some CI/CD pipelines, monitoring tools, and container management UIs require Docker API access and mount the socket for convenience. Developers sometimes mount it during local development to build images inside containers (Docker-in-Docker patterns) and carry the practice into production without considering the security implications.

Example Code

Vulnerabledocker-compose.yml
version: "3.8"
services:
  app:
    image: my-app:latest
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
    environment:
      - NODE_ENV=production
Fixeddocker-compose.yml
version: "3.8"
services:
  app:
    image: my-app:latest
    read_only: true
    security_opt:
      - no-new-privileges:true
    cap_drop:
      - ALL
    environment:
      - NODE_ENV=production
    # Use Docker API over TLS with client certs if access is required
    # Or use a socket proxy like tecnativa/docker-socket-proxy

How Hackers Exploit It

An attacker who gains code execution inside the container can use the mounted Docker socket to create a new container with the host root filesystem mounted. From there, they can read /etc/shadow, install backdoors, access other containers' data, or pivot to other hosts on the network. This is one of the most common container escape techniques.

How to Fix It

Remove the Docker socket mount from production containers. If Docker API access is truly needed, use a socket proxy like tecnativa/docker-socket-proxy that only exposes read-only endpoints. Run containers with read-only filesystems, drop all capabilities, and enable no-new-privileges. For CI/CD, use rootless Docker or Kaniko for building images without socket access.

Frequently Asked Questions

Why is mounting docker.sock dangerous?
The Docker socket is the control interface for the Docker daemon, which runs as root. Any process with access to this socket can create containers with full host access, read any file on the host, and execute commands as root. It is equivalent to giving a container unrestricted root access to the host.
How can I build Docker images in CI without mounting the socket?
Use Kaniko, which builds container images in userspace without requiring a Docker daemon. Alternatively, use Buildah or Podman, which are daemonless and can run rootless. For GitHub Actions, use the docker/build-push-action which handles this securely.
What is a Docker socket proxy?
A Docker socket proxy is a lightweight container (like tecnativa/docker-socket-proxy) that sits between your application and the Docker socket. It filters API requests and only allows specific read-only operations, preventing destructive actions like creating or removing containers.

Related Security Topics

Admin Panel Accessible Without Authentication

Learn about admin panel accessible without authentication and how to fix it.

Debug Mode Enabled in Production

Learn about debug mode enabled in production and how to fix it.

Overly Permissive AWS IAM Policies

Learn about overly permissive aws iam policies and how to fix it.

Check Your Code for This Vulnerability

Run a free scan to check if your site is affected by docker socket exposed to containers.