# Host MITM attack via IPv6 rogue router advertisements (K8S CVE-2020-10749 / Docker CVE-2020-13401 / LXD / WSL2 / ...)

Root in a K8s pod sends rogue IPv6 router advertisements via CAP_NET_RAW, redirecting host IPv6 traffic to an attacker-controlled userspace TCP/IP stack for MITM.

- Payout: unconfirmed
- Severity: medium
- Program: Kubernetes
- Credited: Etienne Champetier / champtar
- Disclosed: 2021-02-28
- CVE: CVE-2020-10749, CVE-2020-13401
- Write-up quality: 8/10
- Original: https://github.com/champtar/blog/tree/main/IPv6_RA_MITM
- Library page: https://bugbountylibrary.com/r/blog%3Agithub-com-champtar-blog-tree-main-ipv6-ra-mitm
- Tags: domain:cloud domain:network impact:internal-access kind:bounty platform:blog sev:medium tech:docker tech:kubernetes technique:chained technique:default-creds vuln:misconfiguration

**Target:** container veth interface / host IPv6 stack (accept_ra)
**Root cause:** CNI-managed host interfaces keep accept_ra=1 with IPv6 forwarding disabled, so the host accepts router advertisements from any L2 peer including containers. Pods retain CAP_NET_RAW by default, letting root in a container emit arbitrary RAs.
**Steps:**
1. Deploy a pod with default capabilities (CAP_NET_RAW present) on a node where ipv6.disable=1 is not set and /proc/sys/net/ipv6/conf/*/accept_ra==1.
2. Compile the smoltcp-based `ipv6mitm` POC with `cargo build --release`.
3. `kubectl cp ipv6mitm ubuntu-pod:/` then `kubectl exec -it ubuntu-pod /bin/bash`.
4. Run `/ipv6mitm -i eth0` to send rogue RAs and serve a dummy HTTP server on all IPv6 addresses.
5. On the host run `curl http://www.google.com -v`; observe IPv6 is now used and response 'ok' comes from the container.
**How found:** Author reasoned that IPv6 is enabled and accepts RAs by default, that managed switches use RA-Guard but container networking ignores this vector, and that default sysctls (accept_ra=1, forwarding=0) make hosts accept RAs from veth peers; verified by building a smoltcp POC and observing curl switch from IPv4 to attacker-served IPv6.
**Exploitation:** Attacker with root in a pod uses CAP_NET_RAW to send rogue router advertisements, installing IPv6 routes on the host that point at the attacker container. Without CAP_NET_ADMIN they cannot use iptables/IP_TRANSPARENT, so they implement a userspace TCP/IP stack (smoltcp) to answer on arbitrary IPv6 addresses. Host HTTP clients preferring IPv6 (AAAA records) connect to the attacker, who can read/modify traffic; chaining with a host-side client RCE (e.g. apt CVE-2019-3462) escalates to host compromise.
**Escalation:** Chain with a host client-side RCE such as apt CVE-2019-3462 to go from container MITM to host compromise; on WSL2/Hyper-V, WPAD abuse extends interception to part of IPv4 traffic and could enable VM escape when chained with a client RCE.
**Insight:** Check whether container/VM interfaces inherit host-level L2 trust assumptions: default accept_ra=1 plus CAP_NET_RAW in pods means any container can inject router advertisements. Test by sending RAs from a pod and watching host route/DNS changes, and look for AAAA-preferring clients to widen the MITM surface.