(When) Docker Bites

A Networking Mystery

Over the past two days, I found myself conducting a complete forensic analysis of my network. Something unexpected had changed the IP address of my main host’s bridge0 interface. Given that a critical React Server Components vulnerability had been released (GHSA-fv66-9v8q-g76r), and I had recently deployed several new Docker containers—some with access to the host Docker socket (I know, not ideal)—I immediately suspected a compromise.

The situation felt serious. By sheer luck, changing the bridge interface address cut all network access to my homelab, which at least contained the potential damage. I examined every Docker image on the system, but found nothing suspicious.

The Investigation

The mysterious IP was 192.168.80.2. I searched for what uses that address by default and stumbled upon obfuscated VPN software—exactly the kind of thing you’d expect to find on a compromised system. My concern grew.

I rechecked and double-checked the suspect container that had access to the host Docker socket (effectively giving it root access). It was only a test container and wasn’t exposed to the public internet, but still—my heart was racing.

After more digging, I finally discovered the culprit.

The Docker Default Address Pool

According to the Docker documentation on networking, the configuration in /etc/docker/daemon.json has the following built-in default:

{
  "default-address-pools": [
    {"base":"172.17.0.0/16","size":16},
    {"base":"172.18.0.0/16","size":16},
    {"base":"172.19.0.0/16","size":16},
    {"base":"172.20.0.0/14","size":16},
    {"base":"172.24.0.0/14","size":16},
    {"base":"172.28.0.0/14","size":16},
    {"base":"192.168.0.0/16","size":20}
  ]
}

There’s the problem: Docker’s default configuration includes 192.168.0.0/16 in its address pool.

Why This Is Problematic

This creates two significant issues:

1. Network Collision: The 192.168.0.0/16 range is the default private network range on most home routers and internal networks. It’s a trusted IP range that’s typically reserved for local infrastructure.

2. Unexpected Address Allocation: While Docker prioritizes the 172.x.x.x ranges (which are fine), as the number of containers and networks grows, Docker inevitably starts using the 192.168.0.0/16 range from the beginning. When it does, it can assign addresses that collide with your actual network infrastructure.

In my case, Docker assigned 192.168.0.x to one of its bridges, which happened to overlap with my main bridge interface. Docker then selected the interface by network and changed the IP address accordingly—creating the false alarm that felt like a security breach.

The Real Lesson

This situation is particularly treacherous for small home networks and labs. For larger enterprise networks that use 10.0.0.0/8 as their private network range, Docker’s defaults are perfectly acceptable. But for home networks where 192.168.0.0/16 is the standard, this is a trap waiting to happen.

What’s Next?

I’m planning to investigate further when time permits. This experience has been frustrating and somewhat unexpected, and I’m considering filing a bug report—though I recognize that for large networks with different private address schemes, these are reasonable defaults.

The key takeaway: if you’re running Docker on a home network, review your default address pools and configure them explicitly to avoid the 192.168.0.0/16 range.