174 Unauthenticated Docker Daemons: Why a Small Number Is Still Worth Acting On

A ZoomEye query for port:2375 returned 174 results in September 2026. Port 2375 is the unauthenticated Docker Remote API. The count is small, and it would be a mistake to read that as reassuring.

What the query returns

A ZoomEye search for port:2375 returned 174 results. Unlike port 9200, where the port may host a variety of services, port 2375 has a narrow meaning: it is the Docker daemon's HTTP API without TLS. A host responding on that port is, with few exceptions, a Docker daemon that accepts commands from anyone who can reach it.
That makes the query unusually precise for a port-based search. The usual caveat about port numbers being conventions rather than identifiers applies less strongly here, because few other services choose 2375.

Why the number is small and the risk is not

The exposure has been well publicised for years, and the operators who were going to fix it have largely done so. What remains is a residual population, and residual populations of this type tend to share characteristics: hosts that were stood up for a specific task and never decommissioned, development environments, and systems where the daemon was configured for convenience and the configuration was never revisited.
The risk profile of an unauthenticated Docker daemon is severe in a way that the count does not convey. The Docker API is not a read-only interface. An attacker who reaches it can start containers, and starting a container with the host filesystem mounted is a documented path to root on the host. From there, the host's credentials, its network position, and any orchestration tokens it holds become available.
A single exposed daemon is therefore not a minor finding. It is a host-level compromise waiting for someone to send an HTTP request.

Why the count stays low but never reaches zero

The persistence of this exposure class is instructive. The fix is well known, the risk is well understood, and the number still does not reach zero. The reason is that the exposure is created by a configuration choice made for convenience, often by someone who does not consider the host internet-facing, and it is never reviewed again.
That is the general lesson for exposure management: findings persist not because the fix is hard but because nobody owns the host.

Using the data

Query port:2375 against your own address ranges. Any result should be treated as a priority finding rather than a routine one, because the exploitation path is short and the impact is host-level.
The remediation is to enable TLS on the Docker daemon and require client certificate authentication, or to bind the daemon to a Unix socket only and reach it through SSH. Removing the public binding is the minimum step.
For organisations that cannot enumerate their own Docker hosts, the query itself is a useful starting point: any host in your address space that answers on 2375 is a host you did not know was running Docker.

Query and method

• Query: port:2375
• Result count: 174
• Collection: ZoomEye, September 2026
• Scope: hosts responding on the specified port; no ownership inference
• Note: port 2375 is the Docker Remote API without TLS, which makes this port query more specific than most ## References
• Docker, protect the Docker daemon socket. https://docs.docker.com/engine/security/protect-access/
• ZoomEye, internet asset search. https://www.zoomeye.ai
• ZoomEye EASM platform documentation. https://easm.zoomeye.org/easm/