No, leave it off unless a legacy tool truly needs it. In Docker Desktop for Windows, the setting to expose the daemon on tcp://localhost:2375 without TLS is disabled by default, and Docker's own settings page warns that exposing the daemon this way can result in remote code execution attacks.
What the setting is
Docker Desktop's settings list "Expose daemon on tcp://localhost:2375 without TLS". The documentation describes it as a way to "allow legacy clients to connect to the Docker daemon", applies it to the Windows Hyper-V backend, and shows the default as disabled.
The daemon API is powerful. Anything that can talk to it can start containers, mount host paths and run commands as root inside them. That is why a reachable, unauthenticated daemon is a serious exposure and not a convenience.
Why localhost is not the whole story
The setting binds to localhost, which sounds safe. Two things weaken that comfort:
- Any local program running as you can reach it, including a malicious package install script.
- Browser based attacks such as DNS rebinding target services that assume localhost means trusted. Whether a given setup is exposed depends on your configuration, so treat it as a risk to test, not a certainty.
The point is that the daemon has no login on that port. The only protection is who can reach it.
Decision guide
| Situation | What to do |
|---|---|
| A tool asks you to tick the box | Check whether it can use the default named pipe or the Docker CLI instead |
| A CI or IDE plugin needs remote access | Use a daemon with TLS, or an SSH based context |
| You ticked it months ago | Check the setting now and turn it off |
| Shared or managed laptop | Ask your admin; settings may be controlled by policy |
How to check
- Open Docker Desktop, then Settings, then General.
- Look for the expose daemon option and confirm it is off.
- From a terminal, confirm nothing answers on port 2375. On Windows,
netstat -anfiltered for 2375 will show whether something is listening.
A related setting worth knowing
Docker Desktop also lists Enhanced Container Isolation, described as a way to "prevent containers from breaching the Linux VM". The documentation notes it requires being signed in with a Docker Business subscription, so it is not available to everyone, and it is off by default.
For the host side of the same risk, see mounting the Docker socket is root on the host.
Safeguard's container image scanning can check images you build and pull for known vulnerable packages. You can try a free scan at gold.safeguard.sh/scan.
Try it yourself
Click through it at your own pace, or open it full screen.
Look at how findings are grouped per layer of the image.
Quick check
Is binding to localhost enough protection?
Not by itself. The port has no authentication, so any local process can use it, and localhost services are a known target for browser based tricks.
Does this setting exist on macOS?
Docker's settings page lists it for Windows with the Hyper-V backend. Check the settings screen on your own platform.
Sources
Last reviewed: 19 October 2026.
