DEV Community

yutianle
yutianle

Posted on

Distributing the Risk: What Global Docker Exposure Numbers Do and Do Not Show

#docker #measurement #risk #zoomeye

Distributing the Risk: What Global Docker Exposure Numbers Do and Do Not Show

A global count of exposed services is easy to quote and hard to act on. The CARBONATO advisory describes a campaign operating across networks, and an internet-wide measurement of Docker remote API exposure is one way to describe its potential reach. Describing reach differs from describing risk, and the difference is where useful analysis happens.
The baseline measurement for this event is straightforward. On 30 September 2026, the day the advisory was published, a query combining the Docker application fingerprint with the conventional unauthenticated remote API port returned 1,032 assets worldwide:

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

Both queries were run with sub_type=all. The first line is the exposure relevant to the advisory. The second is the wider Docker population with no port constraint, useful as a denominator when judging how much of a Docker estate sits on the remote API port.
A single global number hides several things that matter more than the total.
It hides concentration. Exposed daemons are not spread evenly across the Internet. They cluster by hosting provider, by cloud region and by the network practices of the organisations that run them. A defender's relevant figure is rarely the global one; it is the count inside their own address space and their own hosting relationships.
It hides organisational ownership. The 1,032 assets belong to an unknown number of distinct organisations. A count of assets and a count of affected parties are different quantities, and the advisory supplies no victim count to compare against.
It hides configuration state. Since the exposure the advisory describes is conditional on authentication being absent, a count of assets presenting a Docker fingerprint on a port is an upper bound on the affected population rather than a measurement of it. ZoomEye does not authenticate to the services it observes.
It hides change over time. A number recorded on one day is a snapshot. Ports open and close as environments are provisioned and decommissioned, and the same query run next month will not return the same set.
The figure is more useful scoped downward than quoted upward. ZoomEye's field structure lets the same product-and-port query be constrained by geography, organisation or subnet, which converts an internet-wide statement into one about a specific population:

app="Docker" && port="2375"              -> 1,032
app="Docker" && country="US"             -> 1,349
app="Docker" && is_changed=true          ->     0
app="Docker" && is_new=true              ->     0
Enter fullscreen mode Exit fullscreen mode

The geographic line is a Docker-wide figure rather than a remote-API one, and it is included to show the kind of constraint available. The two time-based lines returned zero within ZoomEye's observation windows, indicating that the Docker assets observed here were not flagged as newly appeared or recently changed in that period.
Scoped that way, a global number becomes a set of local questions: how many assets in our range, on our providers, are reachable on the remote API port. Those questions have answers, and the answers are actionable. The global figure is context, and any report including it should label it as such.

References

Top comments (0)