GET /containers/json Requests in Your Logs: Docker Engine API Scanning

203.0.113.7 - - [18/Oct/2026:03:51:11 +0000] "GET /containers/json HTTP/1.1" 404 162 "-" "Go-http-client/1.1"
198.51.100.42 - - [18/Oct/2026:03:51:12 +0000] "GET /v1.40/containers/json HTTP/1.1" 404 162 "-" "python-requests/2.31.0"
192.0.2.88 - - [18/Oct/2026:04:12:03 +0000] "GET /containers/json HTTP/1.1" 404 162 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.0 Safari/537.36"

What the request is

GET /containers/json is a Docker Engine API call. It returns a JSON array describing containers on the daemon — by default the running ones, with image names, container names, command lines, labels, published ports and network details. /images/json, counted by the same pattern, is its sibling for images. The /v1.40/ prefix pins a specific API version; the unversioned form lets the daemon use its current one, and scanners try both because either may be accepted. Both variants show up in these logs.

The daemon normally listens on a Unix socket, where access is controlled by filesystem permissions. It can instead be told to listen on TCP, conventionally port 2375 without TLS and 2376 with it. The API itself carries no login step: whoever can open the socket can call any endpoint on it. That is the whole point of the probe, because the API is not read-only — the same interface that lists containers can also create them, bind host paths into them and start processes. Access to the daemon is effectively root on the host it runs on. Microsoft-style credential files leak secrets; this leaks the machine.

So a 200 to /containers/json is both the reconnaissance result and the proof of access. Why the request lands on ports 80 and 443 at all is simple: scanners replay the same paths against every HTTP service they find, and a minority of hosts genuinely serve them there — through a reverse-proxy location that forwards to docker.sock, a container-management dashboard, or a socket-proxy container published on a public port. See the Docker Engine API reference for what each endpoint returns.

Who sends it

Undirected, internet-wide traffic. The senders are mass scanners sweeping address ranges for management interfaces, cryptomining botnets — exposed Docker daemons have been a standing target for mining deployment for years — and research crawlers cataloguing exposures. Nothing about these requests means your organisation was chosen.

The user agent is weak evidence: Go-http-client, python-requests and curl are common, and so is a copied Chrome string. The shape is clearer. A handful of requests from one address inside a second or two, no Referer, no CSS, JavaScript or image requests, and the same run usually also asking for other unauthenticated management endpoints — /actuator/health, /.env, metadata and API paths. Your log will often show the same addresses on the Spring Boot Actuator and /.env pages.

Is your server exposed?

The web log answers only half the question; the daemon’s listener answers the other half.

# Which Docker API paths were requested, and what they got
awk '$7 ~ /(containers|images)\/json/ {print $9, $7}' /var/log/nginx/access.log \
  | sort | uniq -c | sort -rn | head -20

# Anything that was NOT 404/403 — this is the list that matters
awk '$7 ~ /(containers|images)\/json/ && $9 !~ /^(404|403)$/' /var/log/nginx/access.log

# Ask your own server, from your own server, and read the status code
curl -s -o /dev/null -w '%{http_code}\n' http://127.0.0.1/containers/json
curl -si http://127.0.0.1/v1.40/containers/json | head -12   # look at the headers

# Does the daemon listen on TCP anywhere?
ss -ltnp | grep -E ':(2375|2376)\b'
grep -i hosts /etc/docker/daemon.json 2>/dev/null
systemctl cat docker.service 2>/dev/null | grep -- ' -H '

Repeat the curl checks with the Host header of every vhost you serve — a rule added to the main site and forgotten on a staging or admin vhost is the usual way an internal endpoint stays reachable. Give rotated logs the same awk pass, since an exposure may have been closed after it was used.

How to block it

The durable fix is that the daemon should not be reachable from the network at all: leave it on the Unix socket, use SSH or TLS with client certificates if you must reach it remotely, and keep 2375 and 2376 closed at the firewall and in cloud security groups. Never proxy_pass to docker.sock from a location that does not authenticate first; if a dashboard needs the API, restrict it to the endpoints it uses rather than passing everything through.

Then answer the probe cheaply at the edge:

# Docker Engine API probes — this server proxies no daemon
location ~ ^/(?:v\d+\.\d+/)?(?:containers|images)/json$ {
    access_log off;
    return 404;
}

The pattern is anchored on the exact endpoint names so it cannot swallow a real /images/ directory of static assets, and it covers both the bare and version-prefixed forms. Returning 404 rather than 403 tells the scanner nothing. Alert on any non-404 response to these paths instead of on the requests themselves — the requests will not stop, and only the answers matter.