ZoomEye scan data shows 1.4 million hosts answering on Docker's unencrypted port 2375

Internet-wide scan data shows roughly 1.4 million hosts answering on TCP port 2375, the port the Docker daemon uses when it is configured to accept plain network connections, according to an analysis published on dev.to. The same search index, queried at the same moment, matched only 13,193 hosts against a Docker product fingerprint — a gap of roughly a hundredfold that says a great deal about how exposure gets measured.

Two queries, two answers

The dev.to post describes four queries run against the ZoomEye search index on 26 September 2026, between 04:33 and 04:36 Beijing time (25 September, 20:33 to 20:36 UTC). The query for port 2375 returned 1,436,956 results; the query for the Docker application fingerprint returned 13,193.

The difference follows from what each query matches. The port query finds hosts with something listening on the TCP port the daemon uses for unencrypted network access; the fingerprint query finds hosts whose response the index recognises as Docker. As the author notes, a daemon listening on 2375 has no obligation to announce itself in a way a fingerprint matcher detects, so a host can satisfy the first condition while failing the second.

Two further counts sit between those extremes. A query for port 2376 — the port conventionally used for encrypted daemon connections — returned 1,754,061, which is larger than the 2375 figure. A service-level query, matching traffic the index classified as the Docker protocol, returned 652,954. Taken together, the size of the port numbers is a reminder that network listening is a configuration choice, and a substantial population of deployments made it.

Why an open daemon port matters

The Docker daemon does not authenticate clients at the API level, the post explains. When it listens on a TCP socket, any client that can reach the socket can issue the same commands a local administrator could, and the daemon will carry them out — spinning up containers, bind-mounting host directories and touching the host filesystem.

Docker's default is to listen on a local Unix socket; the other standard protection is where the daemon sits on the network. For any deployment that turned on a network listener, the question that matters is which networks can actually reach it.

What the counts do not prove

The post is explicit about three limits. A port match shows only that something listened at scan time; it says nothing about whether the Docker API actually responded, how the listener was set up, or whether the endpoint remained reachable afterward. Fingerprinting depends on the banner a service happens to return and on matching rules that evolve. And counts on scan indexes drift day to day, so the figures capture a snapshot, not a durable inventory.

False positives cut in both directions. Any process can claim port 2375, and proxies, load balancers or unrelated services can generate port matches that have nothing to do with Docker. Fingerprint-only inventories will therefore miss hosts that answer on the daemon port; port-only inventories will count hosts that never ran Docker at all.

How to use the data

The author's practical advice is to run the port and fingerprint queries side by side and treat divergence between them — together with the service-level query — as a signal in its own right. Use the port query to size the population, narrow it to the geography or network range you are responsible for, then cross-check with the fingerprint and service queries. If a count shifts between scheduled runs, the post suggests treating that as a configuration change worth investigating. For your own estate, it recommends verifying the daemon configuration directly, because edge filtering can hide a host from outside scanners entirely, and a small external count does not prove the socket is closed.

Why it matters

More than a million hosts answering on a port tied to an unauthenticated daemon API is a concrete exposure signal, whatever fraction of them actually runs Docker. The larger lesson is methodological: fingerprint-based asset lists can miss the riskiest hosts precisely because exposed daemons often do not identify themselves. When port, service and fingerprint queries disagree, that disagreement is not noise — it is the information a flat inventory usually lacks.