174 Unauthenticated Docker Daemons and the Control-Plane Exposure Behind Them

A ZoomEye host search for port:2375 returned 174 observable services on 18 September 2026. Port 2375 is the Docker daemon's unencrypted TCP socket. When it is reachable, it is almost always unauthenticated, because the Docker API has no built-in authentication mechanism: access to the socket is access to the daemon.
174 is a small number. It is also a number worth understanding precisely, because the consequence of a single reachable Docker socket is different in kind from the consequence of a reachable web service.

What access to the Docker socket means

The Docker daemon runs as root on the host. Its API allows creating containers, and a container can be created with a bind mount of the host filesystem, with --privileged, or with the host's PID namespace. Any of those options converts API access into host root access. The API also allows reading environment variables from existing containers, which frequently contain credentials for downstream services.
This is why the exposure is treated as a critical finding even at low counts. A reachable unauthenticated Docker API is not a foothold; it is the destination.

Why the number is low

Three factors keep the count in the hundreds rather than the hundreds of thousands. Docker's documentation has warned against exposing the daemon on a TCP socket without TLS for years, and the default configuration uses a Unix socket that is not network-reachable. Cloud providers and managed container services do not expose the daemon. And the exposure that does exist is usually the result of a specific decision: a CI runner that needs to build images, a development host that was never decommissioned, or a monitoring agent that was configured to talk to a remote daemon.
The last category is the one that surprises teams, because the exposure is intentional and documented internally. It is still an unauthenticated root-equivalent API on the internet.

The comparison that reframes the number

174 reachable Docker daemons is small next to 501,664 reachable Redis services. The comparison is useful because it shows that volume and severity are independent axes. Redis exposure is common and often low-impact when the instance is empty. Docker API exposure is rare and always high-impact when the daemon is reachable.
An exposure management programme that ranks findings by count will deprioritise the Docker daemons. A programme that ranks by consequence will fix them first.

What to check and how to fix it

The check is a port scan for 2375 and 2376 across the estate, plus a review of any CI or build infrastructure that talks to a remote daemon. Port 2376 is the TLS variant; a reachable 2376 without client certificate verification is the same problem with a different port number.
The fix is to stop exposing the daemon. Where remote access is genuinely required, use an SSH tunnel to the Unix socket, which is the pattern Docker's own documentation recommends. Where TCP is unavoidable, enable TLS with mutual authentication and restrict the listener to known source addresses. For CI runners, the modern alternative is a rootless or daemonless build tool that does not require socket access at all.

Why this belongs in a ZoomEye workflow

The value of querying 2375 rather than relying on an asset inventory is that Docker daemons are frequently installed outside change control. A developer enables the TCP socket to test something, the host is provisioned by a team that does not file a CMDB entry, and the exposure persists. An external measurement finds what the inventory does not know about.
The same logic applies to the other control-plane ports. A periodic query for 2375, 2376 and the Kubernetes API port 6443 against your own address space is a cheap check with a high consequence if it returns anything unexpected.

Limits

The count describes services that answered on port 2375. It cannot confirm that the API is unauthenticated without issuing a request, and a responsible measurement does not issue that request against systems it does not own. The operational assumption should be that a reachable 2375 is unauthenticated, because that is the default and the alternative requires deliberate configuration.

References

• Docker documentation on protecting the daemon socket and the recommended SSH tunnel pattern
• ZoomEye host search, dork port:2375, collected 18 September 2026