Port 2375: Docker — The Door That Should Stay Closed

Port 2375 is the unencrypted REST API endpoint for Docker. When a system exposes this port, anyone who can reach it gains the ability to create containers, delete containers, mount host filesystems, execute arbitrary commands, and effectively become root on the host machine.

This port carries the power of containerization itself. And therein lies both its beauty and its danger.

What Port 2375 Does

Docker operates on a client-server architecture. The Docker daemon (dockerd) runs in the background, managing containers, images, networks, and volumes. The Docker CLI (docker) sends commands to this daemon. By default, they communicate through a Unix socket at /var/run/docker.sock, which only allows local connections.¹

Port 2375 is what happens when you want Docker to listen over TCP instead of a Unix socket. When enabled, the Docker daemon accepts HTTP requests on this port, exposing its full REST API to the network.²

The API is comprehensive. You can:

• Create, start, stop, and delete containers
• Pull and push images
• Mount host directories into containers
• Execute commands inside running containers
• Access logs, inspect configurations, and manage networks

Every docker command you run translates to an HTTP request against this API. Port 2375 makes that API network-accessible.

How the Docker Engine API Works

The Docker Engine API is a RESTful HTTP interface.³ You can interact with it using curl, any HTTP client library, or Docker's official SDKs for Go and Python.

# List all containers
curl http://localhost:2375/containers/json

# Create a container
curl -X POST http://localhost:2375/containers/create \
  -H "Content-Type: application/json" \
  -d '{"Image": "alpine", "Cmd": ["echo", "hello"]}'

# Start a container
curl -X POST http://localhost:2375/containers/{id}/start

The API is versioned. When making requests, you can specify the version as the first part of the URL path: /v1.43/containers/json. This allows clients to maintain compatibility as the API evolves.⁴

The simplicity is the point. Docker's entire promise was making containers accessible. The Unix socket handles local security. The problem begins when someone exposes this API to the network.

The History: A Five-Minute Demo That Changed Everything

On March 15, 2013, a French-American programmer named Solomon Hykes walked onto the main stage at PyCon in Santa Clara for a five-minute lightning talk. He didn't expect to be on the main stage. He thought lightning talks happened in a small room in the back.⁵

The talk was titled "The Future of Linux Containers."⁶

Solomon demonstrated Docker, a tool his company dotCloud had built internally to power their platform-as-a-service offering. In five minutes, he showed how to package an application and its dependencies into a container, then ship it anywhere. At the five-minute mark, he was abruptly cut off. It didn't matter. The demo had already planted the seed.⁷

Docker didn't invent containerization. Linux had cgroups (contributed by Google in 2007) and namespaces for years.⁸ LXC (Linux Containers) existed. But Docker solved a different problem: usability. It wrapped complex kernel features in a simple interface. docker build. docker run. docker push. Anyone could use it.

Within months, Docker had more momentum than dotCloud ever did. In October 2013, the company renamed itself Docker Inc.⁹ The platform-as-a-service business was abandoned. Docker was the future.

The Docker daemon needed a way for the CLI to communicate with it. For local use, the Unix socket was perfect. For remote management, they needed a TCP option. Port 2375 was chosen for unencrypted connections, port 2376 for TLS-encrypted connections.¹⁰

The convention became standard. Port 2375 is now registered with IANA for Docker's REST API (unencrypted).¹¹

The Security Reality

Here is the truth about port 2375: exposing it to the network without authentication is equivalent to giving remote root access to your system.¹²

The Docker daemon runs as root. Every command it executes, every container it launches, every filesystem it mounts operates with the highest possible privileges on the host operating system.¹³

If an attacker can reach port 2375, they can:

1. Mount the host filesystem into a container and read /etc/shadow, SSH keys, or any file on the system
2. Add their SSH key to /root/.ssh/authorized_keys for persistent access
3. Execute commands directly on the host through a container with elevated privileges
4. Deploy cryptominers that consume your resources
5. Pivot to attack other systems on your network
6. Delete everything and walk away

The attack is trivial:

# Create a container with the host root filesystem mounted
docker -H tcp://vulnerable-host:2375 run -v /:/mnt --rm -it alpine chroot /mnt sh

That's it. You now have a root shell on the host.

The Worms Came

In October 2019, researchers at Palo Alto Networks discovered Graboid, the first cryptojacking worm to spread via Docker containers.¹⁴ Named after the sandworms from the 1990 movie Tremors, Graboid infected over 2,000 unsecured Docker hosts.

The attack vector was simple: scan for open port 2375, find daemons without authentication, deploy a container that mines Monero and spreads to other vulnerable hosts. The worm contained a list of over 2,000 IPs belonging to exposed Docker daemons. 57% were in China, 13% in the United States.¹⁵

Graboid was just the beginning. Kinsing malware followed, targeting thousands of Docker systems for Bitcoin mining.¹⁶ TeamTNT, WatchDog, and other groups launched their own campaigns.¹⁷ The attack surface was too easy, too profitable.

The Numbers Are Staggering

A 2019 analysis found over 5,000 Docker daemons exposed to the Internet, with 10-15% accessible without authentication.¹⁸ The researchers identified more than 1,400 unique unsecured Docker hosts, 8,673 active containers, 17,927 Docker images, and 15,229 volumes—all accessible to anyone on the Internet.

A 2023 Shodan report revealed over 6,000 Docker hosts exposed online, many lacking basic access controls.¹⁹

Right now, at this moment, you can search Shodan for port:2375 Docker and find thousands of misconfigured systems.²⁰ Some are honeypots. Many are not.

The Secure Alternative: Port 2376

Docker provides a secure option. Port 2376 is the TLS-encrypted counterpart to port 2375.²¹ When properly configured with mutual TLS (mTLS), both the server and client must present valid certificates before communication proceeds.

Setting it up requires generating a Certificate Authority, server certificates, and client certificates. It's more work than exposing port 2375. That friction is a feature.

# Start Docker daemon with TLS
dockerd --tlsverify \
  --tlscacert=ca.pem \
  --tlscert=server-cert.pem \
  --tlskey=server-key.pem \
  -H=0.0.0.0:2376

The Docker daemon defaults to port 2376 when TLS is enabled, and port 2375 when it's not.²² The defaults tell you something about priorities.

The Default Is Safety

By default, Docker doesn't listen on any TCP port. It only listens on the Unix socket /var/run/docker.sock, accessible only to root and members of the docker group on the local machine.²³

You have to explicitly configure Docker to listen on port 2375. You have to add -H tcp://0.0.0.0:2375 to the daemon configuration. You have to make the choice to open this door.

The problem is that people make this choice without understanding the consequences. Tutorial blogs show how to enable remote Docker access for convenience. Cloud platforms sometimes default to exposed configurations. Developers testing on cloud VMs expose the port temporarily and forget to close it.

And the worms are always scanning.

Related Ports