CVE-2024-32473 - Unexpected IPv6 Exposure in Moby Container Networks Puts Systems at Risk

Moby is a foundational open source container framework that powers Docker Engine, Docker Desktop, and a broad range of container platforms. In April 2024, a critical vulnerability (CVE-2024-32473) was disclosed—one that exposes containers to IPv6 traffic even when IPv6 is explicitly disabled. Let's break down what happened, how it can be exploited, and how you can secure your systems.

What is CVE-2024-32473?

The vulnerability affects Moby releases up to version 26... At issue is the way network interfaces are configured when containers are launched—specifically, with ipvlan or macvlan networks. These drivers allow a container's network interface to be "attached" directly to the host's network, bypassing much of the isolation typically provided by containers.

In theory, you can launch a container and specify --ipv6=false to keep everything limited to IPv4. Unfortunately, due to this bug, IPv6 was not actually disabled on the container's network interfaces.

Why is this bad?

- Containers can communicate using link-local IPv6: Even on "IPv4-only" networks, containers may directly talk to other machines using IPv6 addresses.
- SLAAC-assigned Global IPv6: If the LAN has router advertisements enabled, containers could obtain globally routable IPv6 addresses using SLAAC.
- Multicast Groups: Network interfaces in containers automatically join IPv6 multicast groups, further increasing the attack surface—for example, opening doors to discovery and enumeration by malicious users on the local network.

As a result, attackers could scan, enumerate, eavesdrop, or potentially exploit services reachable only over IPv6 from a poorly configured container.

Exploitation Scenario

Imagine a company has Docker containers behind a firewall, with the assumption that containers are isolated from the rest of the network using only IPv4. Let’s say you create a network like so:

docker network create --driver=macvlan --subnet=192.168.1./24 --gateway=192.168.1.1 -o parent=eth ipv4onlynet

Now, you run a container and try to enforce IPv4-only networking

docker run --rm -it --network=ipv4onlynet --ipv6=false alpine sh

However, inside the container, IPv6 is still enabled. You can check it within the container

ip a

Output

3: eth@if6: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 150 qdisc noqueue state UP group default 
    link/ether 02:42:c:a8:01:02 brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.2/24 brd 192.168.1.255 scope global eth
       valid_lft forever preferred_lft forever
    inet6 fe80::42:cff:fea8:102/64 scope link 
       valid_lft forever preferred_lft forever

Notice the inet6 entry? This means any service listening on :: (all IPv6 addresses) is exposed—even though you thought IPv6 was "off."

Attack Pathways

1. Network Scanning: A compromised container can now scan your local LAN via IPv6, even on networks locked down for IPv4.
2. Eavesdropping: By joining common IPv6 multicast groups, an attacker can listen for link-local traffic, NDP, or other sensitive info.
3. Unintended Exposure: Misconfigured applications inside containers might listen and serve data over IPv6, thinking it's not on.

Technical Details: Why Did This Happen?

The issue arose because the logic that disables IPv6 (when --ipv6=false is set) did not apply to network interfaces created with macvlan or ipvlan. These interfaces end up on the host’s real network bridge, so their kernel settings for ipv6 were not set to ‘off.’

A simplified pseudocode representation

// This does NOT disable IPv6 on macvlan/ipvlan interfaces, regardless of the dual-stack setting

if networkType == "macvlan" || networkType == "ipvlan" {
    // skips IPv6 sysctl disabling
} else if disableIPv6 {
    netlink.LinkSetSysctl("net.ipv6.conf.<iface>.disable_ipv6", "1")
}

After Patch (v26..2)

Now, the IPv6 disabling logic always applies, honoring the user’s intent when --ipv6=false is set.

Original References

- Official CVE Record
- Moby GitHub Patch PR #47090
- Docker Advisory
- Detailed Analysis by Aqua Security

Remediation & Mitigation

Upgrade your Moby/Docker installation to at least version 26..2. If you can't upgrade immediately, add this flag to _every_ potentially affected container:

docker run --sysctl=net.ipv6.conf.all.disable_ipv6=1 ...

Or in your docker-compose.yml

services:
  app:
    image: yourimage
    sysctls:
      - net.ipv6.conf.all.disable_ipv6=1

This hard-disables IPv6 at the container-level, closing the accidental exposure.

Conclusion

If you use Docker, Docker Desktop, or any Moby-based platform, make sure to review how you handle networking—especially for sensitive or multi-tenant workloads. CVE-2024-32473 throws a spotlight on how defaults and seemingly straightforward flags (--ipv6=false) can sometimes fall short in complex networking situations.

Upgrade now, and don’t be shy about layering on extra network security controls. And double-check what your containers are actually exposed to—not just what you think they’re exposed to.

Stay safe, and keep container networks locked down!

Further Reading:
- Compose Networking Docs
- How to manage sysctls in Docker

Timeline

Published on: 04/18/2024 22:15:10 UTC
Last modified on: 04/19/2024 13:10:25 UTC