Protect the Docker socket

The fix

# The socket must not be reachable by anyone you wouldn't give root to
sudo chown root:docker /var/run/docker.sock
sudo chmod 660 /var/run/docker.sock

# Audit who is in the docker group — this list is your root user list
getent group docker

And in every compose file and docker run you own: remove any bind mount of /var/run/docker.sock.

Why it matters

The Docker daemon runs as root and exposes an API that creates containers with arbitrary mounts and arbitrary privileges. That means anything which can reach the socket can run this:

docker run -v /:/host --privileged -it alpine chroot /host sh

That is a root shell on the host, in one command, using nothing but documented API behaviour. There is no exploit here and no vulnerability to patch — the API is doing exactly what it’s for.

Everything follows from that:

• The docker group is root. Adding someone to it is granting root, and Docker’s documentation says so. Treat getent group docker as the list of people with root on the box.
• Mounting the socket into a container gives that container root on the host. Not root in the container — root on the host.
• Exposing the daemon over TCP publishes a root API to the network.

The socket mount is everywhere, and it’s the same thing every time

This line appears in an enormous number of compose files:

volumes:
  - /var/run/docker.sock:/var/run/docker.sock       # this is root on the host

It’s how Portainer manages containers, how Traefik discovers them, how Watchtower updates them, and how a great many CI runners build images. Each of those has a real reason for it. The reason doesn’t change the consequence: a compromise of that container is a compromise of the host, and containers running web UIs are not a small attack surface.

If a container genuinely needs the API, put a filtering proxy in front of it rather than handing over the raw socket:

services:
  dockerproxy:
    image: tecnativa/docker-socket-proxy
    environment:
      CONTAINERS: 1        # allow read-only container listing
      POST: 0              # deny everything that changes state
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
  traefik:
    environment:
      DOCKER_HOST: tcp://dockerproxy:2375     # no raw socket here

The proxy holds the dangerous mount, exposes only the endpoints you allow, and is a much smaller thing to review than Traefik.

Never expose the daemon over TCP

dockerd -H tcp://0.0.0.0:2375        # an unauthenticated root API, on the network

Port 2375 is plaintext and unauthenticated. Port 2376 is TLS, and TLS alone still isn’t authentication unless you also require client certificates. Internet scanners look for both continuously, and an open 2375 is found in minutes.

If you truly need remote Docker, the right answer in 2026 is not TCP at all — it’s SSH:

export DOCKER_HOST=ssh://user@remote-host

That reuses SSH’s authentication, needs no extra port, no certificate infrastructure, and no daemon flag. It is strictly better than --tlsverify, and it is why exposing 2375/2376 has no remaining justification.

Verify it worked

Check the socket’s permissions and who holds them:

ls -l /var/run/docker.sock
getent group docker

Every name in that group has root. If that list is longer than your sudoers list, that’s the finding.

Find containers that have the socket mounted — this is the check to run now:

docker ps -q | xargs -r docker inspect \
  --format '{{.Name}}: {{range .Mounts}}{{.Source}} {{end}}' | grep docker.sock

Any output is a container with root on your host.

Check the daemon isn’t listening on TCP:

sudo systemctl show docker -p ExecStart | grep -o 'tcp://[^ ]*'
sudo ss -lntp | grep -E ':2375|:2376'

Expect no output from both. ExecStart is where this hides — people look in daemon.json, but the flag is usually in the systemd unit.

Then prove it from another host:

curl -s --max-time 5 http://your.host:2375/version

A JSON version response means an unauthenticated root API is on the network. Treat the host as compromised, not as misconfigured.

Before you apply this

Removing a socket mount breaks the container that had it, and those containers are usually infrastructure — the thing that deploys, monitors or routes. Breaking Traefik takes your sites down; breaking a CI runner stops your deploys.

Work out what it actually needs before you cut:

docker inspect <container> --format '{{json .Config.Env}}' | tr ',' '\n' | grep -i docker

Most socket-mounting containers need a small, read-only subset of the API — list containers, watch events. The docker-socket-proxy pattern above serves that with CONTAINERS: 1, POST: 0 and nothing else. Stage it: run the proxy alongside, point one consumer at it, confirm the consumer still works, then remove the raw mount.

Removing someone from the docker group breaks their workflow immediately, and they will ask for it back. The honest answer is that they need root or they don’t — and if they do, sudo with an audit trail is better than a group membership that grants silent, unlogged root. If they only need to run containers, rootless mode is what actually solves it.

Turning off a TCP listener disconnects remote Docker clients — CI, an IDE, a deploy script. Migrate them to DOCKER_HOST=ssh://... first, confirm each works, then remove the flag from ExecStart and restart the daemon.

Related

• Rootless mode — the structural fix for all of this.
• Container escape — what socket access actually buys an attacker.