DEV Community

jeffrey
jeffrey

Posted on

Why Port 2375 Alone Overstates the Docker Problem

#docker #querydesign #exposure #zoomeye

Why Port 2375 Alone Overstates the Docker Problem

The CARBONATO advisory names TCP port 2375 as the typical way into an exposed Docker host. That detail is operationally useful, and it is easy to over-read. If a team treats "port 2375 is open" as equivalent to "Docker Remote API is exposed without authentication", it will over-count its own risk and misallocate response effort.
A measurement makes the gap concrete. Querying ZoomEye for port 2375 on 30 September 2026 returned 1,437,638 assets. Querying the Docker application fingerprint on that same port returned 1,032.

port="2375"                                   -> 1,437,638
app="Docker" && port="2375"                   ->     1,032
Enter fullscreen mode Exit fullscreen mode

That gap spans three orders of magnitude. It is the distance between a port number and a product identity.
The reason is straightforward. Ports are conventions. Docker's Remote API uses 2375 by default, but nothing reserves the number. Other software listens there, and a port-only query cannot separate a Docker daemon from any other service that happens to bind the same value. ZoomEye's application fingerprint adds the identification step: it classifies the service behind the port, so the result describes Docker assets rather than traffic on a number.
The next layer is subtler still. Within the Docker population, several fingerprints produce different populations:

app="Docker"                        -> 13,246
app="Docker" && service="http"      ->  9,477
http.header.server="Docker"         -> 59,902
banner="Docker"                     -> 354,334
app="Docker" && port="2375"         ->  1,032
Enter fullscreen mode Exit fullscreen mode

Each line maps to a different asset relationship. app="Docker" describes assets ZoomEye identifies as Docker regardless of how they are reached. http.header.server="Docker" describes responses whose Server header names Docker, a weaker and broader signal. banner="Docker" matches banner text and pulls in the widest set. Only the last line constrains both product and the specific exposure path the advisory describes.
None of this makes a port query useless. When the incident itself is about an exposed service, a port query documents the size of the listen surface, and that is a legitimate thing to report. The number becomes misleading when it is presented as a count of vulnerable Docker hosts.
The practical rule is to label the query. "1,437,638 assets respond on port 2375" is accurate. "1,437,638 Docker hosts are exposed" is not. Run the fingerprint query alongside the port query and report both.
ZoomEye supports that comparison because it exposes product and header fields next to port fields, so the same interface can answer the narrow and broad versions of the question. The search below runs the narrow one.
ZoomEye counts describe observed exposure at the time of the query. They do not confirm that any asset accepts unauthenticated API calls, and they do not confirm compromise.

References

Top comments (0)