# Kubernetes man in the middle using LoadBalancer or ExternalIPs (CVE-2020-8554)

Any pod creator can MITM cluster traffic by setting a Service's externalIPs or patching LoadBalancer status to a victim IP, hijacking DNS and internal traffic.

- Payout: unconfirmed
- Severity: medium
- Program: Kubernetes
- Credited: Etienne Champetier / champtar
- Disclosed: 2021-02-28
- CVE: CVE-2020-8554
- Write-up quality: 8/10
- Original: https://github.com/champtar/blog/tree/main/K8S_MITM_LoadBalancer_ExternalIPs
- Library page: https://bugbountylibrary.com/r/blog%3Agithub-com-champtar-blog-tree-main-k8s-mitm-loadbalancer-externalips
- Tags: domain:cloud impact:data-leak impact:internal-access kind:bounty platform:blog sev:medium tech:kubernetes technique:source-review vuln:access-control vuln:info-disclosure vuln:misconfiguration

**Target:** kube-proxy Service ExternalIPs / LoadBalancer status
**Root cause:** kube-proxy programs ExternalIPs and LoadBalancer ingress IPs into the node's kube-ipvs0/iptables rules without validating that the IP belongs to the service, so any user able to create a Service can claim arbitrary IPs.
**Steps:**
1. Create a pod/deployment running an echoserver listening on 8080/8443 in namespace `kubeproxy-mitm`.
2. Create a ClusterIP Service with `externalIPs: [<victim_IP>]` selecting the echoserver, or a LoadBalancer Service and PATCH `/api/v1/namespaces/kubeproxy-mitm/services/mitm-lb/status` with `{"status":{"loadBalancer":{"ingress":[{"ip":"<victim_IP>"}]}}}`.
3. kube-proxy programs the victim IP into kube-ipvs0/iptables, routing traffic destined to that IP to the attacker pod.
4. Optionally remove the selector and create an Endpoints object pointing to an external server to exfiltrate traffic.
5. Works for TCP and UDP (e.g. DNS to 8.8.8.8:53).
**How found:** While working around a broken MetalLB, the author set a Service's externalIPs to node IPs; kube-proxy added those IPs to kube-ipvs0 and broke inter-node communication, revealing that arbitrary IPs can be claimed. The light bulb: set externalIPs to any IP to intercept its traffic.
**Exploitation:** Attacker with permission to create Services sets externalIPs or patches LoadBalancer status to a target IP (external IP, ClusterIP, pod IP, or 127.0.0.1). kube-proxy then routes all node traffic to that IP to the attacker-controlled pod, enabling interception of DNS, internal API calls, and other services; traffic can be forwarded to an external endpoint for exfiltration.
**Escalation:** Chaining MITM of ClusterIP/pod IPs and DNS (UDP 53) allows credential and token theft from other workloads, escalating to broader cluster compromise.
**Insight:** When a controller programs addresses into host routing (IPVS/iptables), test whether unprivileged Service fields like externalIPs or status.loadBalancer.ingress are validated against ownership; try claiming ClusterIP, pod IP, 127.0.0.1, and DNS server IPs, and check UDP too.