Port 2375 (Docker API) is the default unencrypted TCP port for the Docker remote API. If exposed, it can allow remote control of containers and, in some deployments, host compromise. Keep the API off public networks, use the protected TLS endpoint instead, and monitor for unauthorised API requests and container creation.
What Port 2375 Means in Docker Security
Port 2375 is the Docker remote API over plain TCP, which means anyone who can reach it may be able to issue container lifecycle commands. In practice, that turns a management endpoint into a direct control plane for the host.
That is why exposed docker api are treated as high-risk infrastructure rather than ordinary application ports. A forgotten listener, a permissive security group, or a misrouted network path can expose the full runtime authority of Docker to untrusted networks.
How the Docker API on 2375 Becomes Dangerous
The danger is not the port number itself, but the authority behind it. Docker API calls can start containers, mount host paths, attach networking, pull images, and inspect runtime state, so a successful API connection can become container takeover or, in some deployments, host compromise.
That risk is amplified when the API is reachable from the public internet or from broad internal networks. An attacker does not need to exploit a complex parser flaw if the management plane is already exposed and unauthenticated.
For a broader view of how open network services and container interfaces fit into defensive port hygiene, see the Network Ports and Protocols Security Guide.
Exposure Checks and Safer Deployment Patterns
Checking exposure starts with inventory. Organisations need to know which hosts, clusters, and development systems bind the Docker API, which interfaces they listen on, and whether firewall rules, cloud security groups, or host networking make 2375 reachable beyond intended admin paths.
The safer pattern is to avoid cleartext remote API exposure and use the protected TLS endpoint instead. That keeps the management channel under authenticated transport protections and reduces the chance that a stray scan or weak network segment becomes a control-plane compromise.
Use NIST SP 800-190 Container Security to anchor container platform hardening, and consult OWASP API Security Top 10 for API exposure and authorisation failure patterns that often govern management endpoints like this one.
Monitoring, Detection, and Post-Exposure Review
Because exposed Docker APIs are commonly abused for unauthorized container creation, defenders should watch for new containers, unusual image pulls, unexpected bind mounts, and API requests from hosts that should never administer Docker. Those events often indicate reconnaissance, persistence, or lateral movement rather than routine administration.
If exposure is discovered after the fact, review the host as a potential compromise point, not just a misconfiguration. That means checking for unknown containers, altered startup state, suspicious volumes, and any secrets, tokens, or keys that may have been visible to a container started through the API.
Relevant attack behaviour is well captured in TeamTNT worm 2020, which used exposed Docker APIs to spread and steal cloud credentials, and in Carbonato botnet 2026, which shows how exposed Docker hosts can be turned into credential theft and abuse infrastructure.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-17 — Remote Access | Docker API exposure is a remote management path that needs controlled access. |
| IA-2 — Identification and Authentication (Organizational Users) | Remote API administration depends on strong authenticated administrative access. | |
| AU-12 — Audit Record Generation | Unauthorized API calls and container creation require audit visibility for detection. | |
| Recommendation — Restrict remote Docker API access to approved admin paths and authenticated transport. Require strong identification and authentication before allowing Docker administration. Generate and retain audit records for Docker API requests and container lifecycle actions. | ||
| CIS Controls v8 | CIS-4 — Secure Configuration of Enterprise Assets and Software | Exposed Docker API endpoints are a configuration weakness that needs hardening. |
| Recommendation — Harden Docker host and network configuration so 2375 is not exposed publicly. | ||
Practitioner Guidance
Why practitioners should care: Port 2375 is one of those services where a network exposure can immediately become an execution problem. If it is reachable outside a tightly controlled admin boundary, assume the blast radius includes container creation, host interaction, and possible credential exposure.
What to watch for: Treat any unexpected API traffic, new container launches, or remote management from non-admin sources as a security event. The safest operational stance is to keep the cleartext endpoint unreachable and require the protected transport path for legitimate administration.
Practitioner takeaway: If you can reach 2375 from an untrusted network, you do not just have an exposed port, you have an exposed control plane.