Docker Port Mapping to 127.0.0.1 Does Not Prevent External Access: Vulnerability and Mitigation

Recently a Hacker News post highlighted a serious security flaw in Docker where exposing a container port to the loopback address (e.g., -p 127.0.0.1:80:80 ) does not actually prevent external access.

The issue stems from an iptables rule automatically added by Docker that forwards traffic destined for the container’s IP (e.g., 172.17.0.2:80 ) regardless of the source address, allowing anyone on the network to reach the service.

A proof‑of‑concept demonstrates the problem by running a PostgreSQL container on host A with -p 127.0.0.1:5432:5432 , adding a route on host B to the Docker subnet, and then scanning or connecting to the PostgreSQL service from B, which succeeds.

The proposed fix is to tighten the iptables rule so that only traffic arriving on the specified interface and source network is accepted. Example improved rules restrict access to the loopback interface for 127.0.0.1/8 or to a specific LAN subnet (e.g., 192.168.0.0/24 ).

In practice, Docker should default to binding to 127.0.0.1 only when no explicit IP is provided, and users should be warned that mapping to any host address exposes the service externally unless additional firewall rules are applied.

Reference: Hacker News discussion