CVE-2026-32254: 
NixOS vulnerability analysis and mitigation

CVE-2026-32254 is an improper access control vulnerability in kube-router's proxy module that allows authenticated users with Service creation permissions to inject arbitrary externalIPs or loadBalancer IPs into node-level network configuration without validation. It affects all kube-router versions prior to 2.8.0 running on Kubernetes. The vulnerability was reported by researchers @b0b0haha and @j311yl0v3u, disclosed via GitHub Security Advisory GHSA-phqm-jgc3-qf8g on March 17, 2026, and patched in v2.8.0 released March 16, 2026. It carries a CVSS v3.1 base score of 7.1 (High) (GitHub Advisory, kube-router v2.8.0).

The root cause is CWE-284 (Improper Access Control): the buildServicesInfo() function in pkg/controllers/proxy/network_services_controller.go unconditionally copies Service.spec.externalIPs and status.loadBalancer.ingress[].ip into node network configuration (kube-dummy-if interface, IPVS virtual services, LOCAL routing table) without validating them against the --service-external-ip-range parameter. That parameter was only consumed by the network policy (netpol) module for firewall rules, creating a gap between administrator expectations and actual enforcement. An attacker with namespace-scoped Service CRUD permissions can exploit this over the network (no elevated cluster-admin privileges required) by simply creating or modifying a Service resource with a malicious IP in spec.externalIPs or via a LoadBalancer status update. The vulnerability is analogous to CVE-2020-8554, which documented the same design limitation in upstream Kubernetes kube-proxy (GitHub Advisory, Patch Commit).

An authenticated user with namespace-scoped Service create/update permissions can bind arbitrary virtual IPs (VIPs) on all cluster nodes, enabling cluster-wide traffic hijacking and denial of service against critical cluster services such as kube-dns. If an attacker sets an externalIP that overlaps with an existing ClusterIP (e.g., kube-dns at 10.96.0.10), the legitimate IPVS real servers are fully replaced by attacker-controlled endpoints during the stale-endpoint cleanup cycle, redirecting all traffic for that VIP:port. The CVSS assessment reflects high availability impact and low integrity impact, with no direct confidentiality impact — though traffic redirection could enable man-in-the-middle scenarios in multi-tenant clusters (GitHub Advisory).

A proof-of-concept is publicly available in the GitHub Security Advisory, containing complete kubectl commands and Service YAML manifests demonstrating DNS DoS, VIP binding, and traffic hijacking scenarios against a real kube-router cluster (GitHub Advisory). No in-the-wild exploitation has been observed as of the time of disclosure. The EPSS score is approximately 0.034% (low probability of near-term exploitation). The vulnerability is not listed in the CISA KEV catalog. Exploitation requires only low privileges (namespace-scoped Service CRUD), making it accessible to any tenant in a multi-tenant cluster.

1. Reconnaissance: Identify a target Kubernetes cluster running kube-router prior to v2.8.0 with the service proxy module enabled (--run-service-proxy=true). Confirm that the DenyServiceExternalIPs feature gate is not enabled (disabled by default through Kubernetes v1.31).
2. Obtain Service permissions: Use a compromised or legitimately granted namespace-scoped service account with create/update permissions on Service resources (e.g., a CI/CD developer account in attacker-ns).
3. Scenario A — DNS DoS: Create a Service with spec.externalIPs set to the kube-dns ClusterIP (e.g., 10.96.0.10) and point endpoints to attacker-controlled pods. During kube-router's stale-endpoint cleanup cycle, legitimate kube-dns IPVS real servers are replaced, causing cluster-wide DNS resolution failure.

   kubectl --as=system:serviceaccount:attacker-ns:cicd-developer apply -f - <<EOF
   apiVersion: v1
   kind: Service
   metadata:
     name: dns-hijack
     namespace: attacker-ns
   spec:
     externalIPs:
     - 10.96.0.10
     ports:
     - port: 53
       protocol: UDP
   EOF

4. Scenario B — Arbitrary VIP binding: Create a Service with any desired external IP (e.g., a public IP or internal infrastructure IP) to intercept traffic destined for that address on all cluster nodes.
5. Scenario C — LoadBalancer IP hijacking: Create a LoadBalancer-type Service and manipulate status.loadBalancer.ingress to include a target IP, causing kube-router to program it into IPVS and the kube-dummy-if interface cluster-wide.
6. Achieve objective: Traffic for the hijacked VIP is redirected to attacker-controlled pods, enabling data interception, service disruption, or lateral movement within the cluster (GitHub Advisory).

• Kubernetes API Logs: Unexpected Service creation or update events in non-privileged namespaces with spec.externalIPs set to ClusterIP ranges (e.g., 10.96.0.0/12) or unusual external addresses; audit log entries showing system:serviceaccount:<namespace>:<name> creating Services with externalIPs.
• Network: Unexpected IPs appearing on the kube-dummy-if interface on cluster nodes (detectable via ip addr show kube-dummy-if); IPVS virtual services for unexpected VIPs (detectable via ipvsadm -Ln); entries in the kube-router-svip ipset for unauthorized IPs.
• Cluster State: Services in tenant namespaces with spec.externalIPs overlapping with --service-cluster-ip-range (e.g., kube-dns IP); LoadBalancer services with status.loadBalancer.ingress IPs not allocated by the cluster's load balancer controller.
• Availability: Sudden cluster-wide DNS resolution failures or degraded connectivity to ClusterIP services, potentially indicating a kube-dns VIP conflict (GitHub Advisory).

Upgrade kube-router to v2.8.0 or later, which introduces the --strict-external-ip-validation flag (enabled by default) that validates externalIPs against --service-external-ip-range and loadBalancerIPs against --loadbalancer-ip-range before programming them into IPVS (kube-router v2.8.0). Before upgrading, ensure all legitimate service IPs are covered by the configured CIDR ranges, or temporarily set --strict-external-ip-validation=false to avoid breaking existing services (not recommended for multi-tenant clusters). Available workarounds for unpatched versions include: enabling the Kubernetes DenyServiceExternalIPs feature gate, deploying an admission webhook or policy to validate service IPs, restricting Service creation/update RBAC to trusted users only, monitoring Service changes for unauthorized IP assignments, and applying BGP prefix filtering to prevent invalid routes from propagating (GitHub Advisory).

The kube-router maintainers proactively released v2.8.0 ahead of the advisory publication to give operators time to upgrade, and credited the researchers @b0b0haha and @j311yl0v3u for responsible disclosure (kube-router v2.8.0). The advisory explicitly contextualizes the issue against CVE-2020-8554, noting this vulnerability class is not unique to kube-router and affects kube-proxy and other service proxy implementations. The fix was also picked up by openSUSE security announcements and Linux security advisory feeds (GitHub Advisory).