Is port 2375 (Docker API) exposed to the internet without TLS?

Why an open Docker API is as bad as it sounds

IANA registers port 2375/tcp for Docker’s REST API in plain text. Docker’s own documentation on protecting the daemon socket explains that the daemon normally communicates over a non-networked Unix socket, and only optionally over SSH or a TLS-secured TCP socket — plain, unauthenticated TCP was never the intended production configuration. The reason this matters so much more than a typical exposed service is privilege: the Docker daemon runs as root, and its API can be told to start a container with the host’s own root filesystem mounted inside it. A single API call that most people would consider routine container management is, with no authentication in front of it, equivalent to handing out an unauthenticated root shell on the entire host.

Who’s actually looking for this

This is not a theoretical attack chain. The Hacker News reported on a 2024 malware campaign that specifically scans the internet for Docker hosts with the API exposed on port 2375, then uses the access to deploy cryptocurrency-mining payloads at scale. Security researchers have separately documented the Kinsing malware family running the same pattern for years: find an exposed Docker (or Redis) instance, use it to run an attacker-controlled container, and deploy a cryptominer. Some campaigns go a step further once they’ve compromised a host — they add a cron job that uses the host’s own firewall tools to close port 2375 behind them, locking out both the original administrator’s oversight and any competing attacker scanning for the same opening.

How to check your own exposure

AdminKit’s planned open ports check is designed to test whether port 2375 and other commonly-exposed management ports on your own public IP respond from outside your network. Because this single exposure is equivalent to full host compromise rather than a partial one, confirming it directly is worth prioritizing over most other port checks on this list.

How to fix it

• Stop exposing the Docker API over plain, unauthenticated TCP — if remote access is genuinely required, enable mandatory TLS with client-certificate verification as described in Docker’s own daemon-socket protection guide, or use SSH-based remote access instead.
• Check what’s actually listening with a command like ss -tlnp | grep 2375 on the host itself; it should not show a public address bound to that port.
• Restrict access to the Docker API, however it’s configured, to a small set of trusted management hosts via a firewall rule — never a public, unrestricted address.
• Audit the host for signs of prior compromise if you find the port was open, including unfamiliar containers, cron jobs, or firewall rule changes you didn’t make.

Defensive use only

Every check this page links to is for assets you own or are explicitly authorized to test. Never scan, probe, or attempt to connect to a network or device you don’t control — AdminKit’s active checks only ever run against the IP making the request or an asset you’ve verified ownership of. See our Disclaimer and Acceptable Use Policy for the full terms.