patch services
Adding or modifying externalIPs on an existing Service (CVE-2020-8554) makes kube-proxy DNAT traffic for that address to the attacker's pod.
The API server does not validate it and accepts even another Service's ClusterIP.
Which rule wins is settled by the kube-proxy dataplane rather than by validation, so a collision is never returned as an error and nothing in the audit trail marks it as failed.
Note:
CVE-2020-8554 is a design issue: users who can create or modify Services with spec.externalIPs can intercept traffic to those IPs.
Mitigate with admission policy and strict RBAC; do not rely on a Kubernetes patch level alone.
- API Group
- (core)
- Scope
- namespaced
- Audit Level
- RequestResponse
Escalation Paths
Create or patch a Service and set spec.externalIPs to an address used by another pod, a node, or an off-cluster host.
kube-proxy programs DNAT for that address on every node, sending traffic for it to the Service's endpoints.
NetworkPolicy does not contain this, since policy selects on pod addresses rather than on a Service's externalIPs.
The API server accepts an address already claimed as another Service's ClusterIP.
Which rule wins is decided by the dataplane, not by validation.
Behaviour differs by kube-proxy mode.
iptables favours the first matching rule, while IPVS and eBPF dataplanes resolve collisions on their own terms, so confirm the mode before relying on precedence.
Additional rights needed:
Note:
spec.externalIPs is deprecated as of 1.36 and warns on write, but it stays fully functional.
kube-proxy still programs the DNAT identically.
Deprecated is not mitigated (CVE-2020-8554).
Restricting it requires an admission webhook that validates externalIPs.