Docker Engine TCP Socket Exposure
A Docker Engine was listening on TCP port 2375 without authentication, letting any host on the network list containers, pull images, and control the daemon. I confirmed the unauthenticated access and identified the controls to secure remote Docker management.
Status: ASSESSED · VERIFIED
TOOLS
Objective
I set out to assess whether a Docker Engine's TCP socket was exposed to the network and whether remote users could interact with the Docker daemon without authentication.
Scenario
A Docker host was configured to listen for remote management connections on TCP port 2375, the default Docker API port. I wanted to determine whether authentication or TLS was enforced, and what an unauthenticated user could do through the exposed API.
What I found
FINDING 01 (CRITICAL): DOCKER API ACCESSIBLE WITHOUT AUTHENTICATION
A port scan identified TCP 2375 as open, running Docker Engine 20.10.20. The API responded to unauthenticated requests, returning version information and accepting management commands.
Port: 2375/tcp (open)
Service: Docker Engine 20.10.20
Authentication: None
TLS: Not configuredFINDING 02 (CRITICAL): FULL REMOTE CONTROL OF THE DOCKER DAEMON
Through the unauthenticated API, I could list running containers, enumerate networks and images, and issue management commands. Any host that could reach port 2375 had full administrative control of the Docker Engine.
Containers: Listed (running and stopped)
Networks: Listed
Images: Listed
Management commands: Accepted without credentialsWhat I did
- Scanned the target
I used Nmap to identify the open Docker API on port 2375.
- Tested API access
A cURL request to the
/versionendpoint returned Docker Engine details without authentication. - Enumerated the daemon
I used the Docker CLI with the remote host flag to list containers, networks, and images.
- Documented the exposure
The daemon was fully controllable from any host on the network.
EVIDENCE
# Remote Docker API assessment
Nmap: Port 2375 open, Docker 20.10.20
cURL /version: Responded without authentication
Docker CLI: Listed containers, networks, images remotely
Access level: Full Docker daemon administrationValidation
The Docker API responded to unauthenticated requests, and full management access was confirmed through the Docker CLI. Any network-reachable host could control the daemon.
Before and after
| CONTROL | BEFORE | AFTER |
|---|---|---|
| TCP 2375 | Open, unauthenticated | Exposure documented |
| TLS authentication | Not configured | Recommended: mutual TLS |
| Network access | Any host on network | Recommended: firewall to management hosts only |
| API authentication | None | Recommended: TLS client certificates |
| Docker contexts | Not used | Recommended: SSH-based remote management |
What I recommend
- 01Disable the TCP socket and use SSH-based Docker contexts for remote management.
- 02If TCP is required, enforce mutual TLS authentication so only clients with valid certificates can connect.
- 03Restrict network access to the Docker API port using firewall rules, allowing only authorised management hosts.
- 04Monitor for unexpected connections to the Docker API port.
- 05Review Docker daemon configuration regularly for unintended network exposure.
“An exposed Docker TCP socket can turn a container management interface into a remotely accessible administrative surface, making network exposure and access control critical parts of Docker security.”
SKILLS IT PROVES
- Docker Security
- Container Security
- Network Security
- Vulnerability Assessment
- Network Enumeration
- Service Enumeration
- Docker Engine Administration
- Docker API Security
- Access Control
- Network Segmentation
- Infrastructure Security