The Unauthenticated Docker API: 298,430 Exposed Endpoints and Why Port 2375 Still Matters

The Docker daemon's remote API has no authentication of its own. Anyone who can reach the socket can start containers, mount host directories and read environment variables. A ZoomEye query for service="docker" && port="2375" returns 298,430 matching assets, which makes this one of the largest directly exploitable exposures on the public internet.

The problem

Port 2375 is the unencrypted, unauthenticated Docker API endpoint. Port 2376 is the TLS-protected equivalent. The distinction is the entire security control: 2375 assumes the network is trusted, and on the public internet the network is not. When a host exposes 2375, the API answers requests from anyone, and the API is powerful by design. It can create containers, and a container can be created with the host filesystem mounted.

How the measurement was taken

The figure comes from a single ZoomEye query executed on 2026-09-16:

• Search dork: service="docker" && port="2375"
• Scope: sub_type=all
• Result: 298,430 matching assets The query matches services that ZoomEye identifies as Docker on port 2375. It measures reachable endpoints, not confirmed compromises. Some matches may be behind additional network controls that ZoomEye cannot observe from the outside, and some may be honeypots. The number is a scale indicator for a configuration pattern, not a breach count. ## Why this exposure is unusually severe Most exposed services require an attacker to find a second flaw: a weak password, a known CVE, a misconfigured plugin. An open Docker API does not. The API is the intended administrative interface, and it is being offered to the internet without authentication. The practical consequences follow directly:
• Host filesystem access. A container can be started with a bind mount of /, after which the host's files, including SSH keys and cloud credentials, are readable and writable.
• Privileged containers. The API accepts --privileged, which removes most container isolation and permits kernel-level operations.
• Credential harvesting. Container environment variables and mounted secrets are visible through the API, and they frequently contain registry credentials and cloud role tokens.
• Resource abuse. The host can be used for cryptomining or as a staging point for further attacks, with the owner's billing account paying for it. This is why the Docker API appears in cloud security guidance alongside exposed Kubernetes control planes: it is an administrative interface that grants administrative outcomes. ## How the exposure usually happens The pattern is consistent. A developer follows a tutorial or a vendor's quick-start guide, adds -H tcp://0.0.0.0:2375 to the daemon configuration to let a CI job or a remote client talk to Docker, and the host is placed on a network with a public address. The configuration is intentional at the time it is made and forgotten afterwards. In container platforms, the equivalent is a port mapping that publishes the daemon socket beyond the host. ## Practical next steps for defenders Find the flag. Search daemon configuration for tcp:// bindings. On Linux this is typically in the systemd unit override or /etc/docker/daemon.json. Any binding to 0.0.0.0 or a public address is the finding. Use the socket, not the port. Local clients should talk to /var/run/docker.sock. Remote access should go through SSH or an authenticated proxy rather than a raw TCP endpoint. If remote access is required, use 2376 with mutual TLS. Generate a server certificate and require client certificates. Without client certificate verification, the TLS port provides confidentiality but not access control. Restrict by firewall as a second layer. Even a correctly configured daemon should not be reachable from arbitrary source addresses. Limit access to known management networks. Check for existing compromise. If an endpoint was exposed, review running containers, recent image pulls, new volumes and outbound connections. Attackers commonly leave a container running for persistence, and it may be named to blend in. Inventory container hosts separately. These hosts often sit outside the standard server inventory, which is precisely why they remain exposed. ## Limitations A service fingerprint cannot determine whether a specific endpoint is unauthenticated, whether the daemon has been hardened with an authorization plugin, or whether the host is a decoy. ZoomEye observes what the service presents to the network. The count should be read as evidence that a well-known, easily avoided misconfiguration remains widespread, and that any organisation running container infrastructure should verify its own daemon configuration rather than assume it is correct. ## References
• Docker documentation, "Protect the Docker daemon socket": https://docs.docker.com/engine/security/protect-access/
• Docker documentation, "Docker daemon configuration overview": https://docs.docker.com/engine/daemon/
• CIS Docker Benchmark (daemon configuration and network exposure controls): https://www.cisecurity.org/benchmark/docker
• ZoomEye search interface: https://www.zoomeye.ai/