{ "document": { "category": "csaf_base", "csaf_version": "2.0", "distribution": { "tlp": { "label": "WHITE" } }, "lang": "en", "notes": [ { "category": "legal_disclaimer", "text": "The Netherlands Cyber Security Center (henceforth: NCSC-NL) maintains this portal to enhance access to its information and vulnerabilities. The use of this information is subject to the following terms and conditions:\n\nThe vulnerabilities disclosed in this portal are gathered by NCSC-NL from a variety of open sources, which the user can retrieve from other platforms. NCSC-NL makes every reasonable effort to ensure that the content of this portal is kept up to date, and that it is accurate and complete. Nevertheless, NCSC-NL cannot entirely rule out the possibility of errors, and therefore cannot give any warranty in respect of its completeness, accuracy or real-time keeping up-to-date. NCSC-NL does not control nor guarantee the accuracy, relevance, timeliness or completeness of information obtained from these external sources. The vulnerabilities disclosed in this portal are intended solely for the convenience of professional parties to take appropriate measures to manage the risks posed to the cybersecurity. No rights can be derived from the information provided therein.\n\nNCSC-NL and the Kingdom of the Netherlands assume no legal liability or responsibility for any damage resulting from either the use or inability of use of the vulnerabilities disclosed in this portal. This includes damage resulting from the inaccuracy of incompleteness of the information contained in it.\nThe information on this page is subject to Dutch law. All disputes related to or arising from the use of this portal regarding the disclosure of vulnerabilities will be submitted to the competent court in The Hague. This choice of means also applies to the court in summary proceedings." } ], "publisher": { "category": "coordinator", "contact_details": "cert@ncsc.nl", "name": "National Cyber Security Centre", "namespace": "https://www.ncsc.nl/" }, "title": "CVE-2026-32254", "tracking": { "current_release_date": "2026-03-27T00:14:45.066095Z", "generator": { "date": "2026-02-17T15:00:00Z", "engine": { "name": "V.E.L.M.A", "version": "1.7" } }, "id": "CVE-2026-32254", "initial_release_date": "2026-03-17T17:54:42.195914Z", "revision_history": [ { "date": "2026-03-17T17:54:42.195914Z", "number": "1", "summary": "CVE created.| Source created.| CVE status created. (valid)| Description created for source.| CVSS created.| References created (4).| CWES updated (1)." }, { "date": "2026-03-17T17:54:43.781503Z", "number": "2", "summary": "NCSC Score created." }, { "date": "2026-03-18T03:38:50.597714Z", "number": "3", "summary": "Source created.| CVE status created. (valid)| Description created for source.| CVSS created.| Products created (1).| References created (3).| CWES updated (1)." }, { "date": "2026-03-18T03:38:55.213279Z", "number": "4", "summary": "NCSC Score updated." }, { "date": "2026-03-18T04:25:25.501448Z", "number": "5", "summary": "Source created.| CVE status created. (valid)| Description created for source.| CVSS created.| References created (3).| CWES updated (1)." }, { "date": "2026-03-18T04:25:32.970301Z", "number": "6", "summary": "NCSC Score updated." }, { "date": "2026-03-18T07:35:03.751150Z", "number": "7", "summary": "NCSC Score updated." }, { "date": "2026-03-18T14:39:15.960029Z", "number": "8", "summary": "Unknown change." }, { "date": "2026-03-18T15:56:47.937963Z", "number": "9", "summary": "Source created.| CVE status created. (valid)| EPSS created." }, { "date": "2026-03-18T15:56:49.965584Z", "number": "10", "summary": "NCSC Score updated." }, { "date": "2026-03-19T15:30:52.010442Z", "number": "11", "summary": "Source created.| CVE status created. (valid)| Description created for source.| CVSS created.| References created (4).| CWES updated (1)." }, { "date": "2026-03-19T15:31:05.267744Z", "number": "12", "summary": "NCSC Score updated." }, { "date": "2026-03-20T09:31:27.953816Z", "number": "13", "summary": "Source connected.| CVE status created. (valid)| EPSS created." }, { "date": "2026-03-20T18:15:54.860300Z", "number": "14", "summary": "Source created.| CVE status created. (valid)| Description created for source.| CVSS created.| Products created (1).| Product Identifiers created (1).| Exploits created (1).| References created (3).| CWES updated (1)." }, { "date": "2026-03-20T18:15:56.726337Z", "number": "15", "summary": "NCSC Score updated." }, { "date": "2026-03-20T19:55:46.222067Z", "number": "16", "summary": "References created (1)." }, { "date": "2026-03-23T05:16:07.947339Z", "number": "17", "summary": "References removed (1)." }, { "date": "2026-03-24T20:56:35.325858Z", "number": "18", "summary": "References created (1)." }, { "date": "2026-03-24T20:56:38.564998Z", "number": "19", "summary": "NCSC Score updated." }, { "date": "2026-03-27T00:13:25.718689Z", "number": "20", "summary": "Source created.| CVE status created. (valid)| Description created for source.| CVSS created.| Products created (1).| References created (4).| CWES updated (1)." }, { "date": "2026-03-27T00:13:28.962448Z", "number": "21", "summary": "NCSC Score updated." }, { "date": "2026-03-27T00:14:23.932676Z", "number": "22", "summary": "Source created.| CVE status created. (valid)| Description created for source.| References created (4)." } ], "status": "interim", "version": "22" } }, "product_tree": { "branches": [ { "branches": [ { "branches": [ { "category": "product_version_range", "name": "vers:unknown/<2.8.0", "product": { "name": "vers:unknown/<2.8.0", "product_id": "CSAFPID-5841020" } }, { "category": "product_version_range", "name": "vers:unknown/>=0|<2.8.0", "product": { "name": "vers:unknown/>=0|<2.8.0", "product_id": "CSAFPID-5920138" } } ], "category": "product_name", "name": "kube-router" } ], "category": "vendor", "name": "cloudnativelabs" }, { "branches": [ { "branches": [ { "category": "product_version_range", "name": "vers:unknown/<2.8.0", "product": { "name": "vers:unknown/<2.8.0", "product_id": "CSAFPID-5873816", "product_identification_helper": { "cpe": "cpe:2.3:a:kube-router:kube-router:*:*:*:*:*:kubernetes:*:*" } } } ], "category": "product_name", "name": "kube-router" } ], "category": "vendor", "name": "kube-router" } ] }, "vulnerabilities": [ { "cve": "CVE-2026-32254", "notes": [ { "category": "description", "text": "# kube-router Proxy Module Does Not Validate ExternalIPs or LoadBalancer IPs Against Configured Ranges\n\n## Summary\n\nThis issue primarily affects multi-tenant clusters where untrusted users are granted namespace-scoped permissions to create or modify Services. Single-tenant clusters or clusters where all Service creators are trusted are not meaningfully affected.\n\nThe kube-router proxy module's `buildServicesInfo()` function directly copies IPs from `Service.spec.externalIPs` and `status.loadBalancer.ingress` into node-level network configuration (kube-dummy-if interface, IPVS virtual services, LOCAL routing table) without validating them against the `--service-external-ip-range` parameter. A user with namespace-scoped Service CRUD permissions can bind arbitrary VIPs on all cluster nodes or cause denial of service to critical cluster services such as kube-dns.\n\nThe `--service-external-ip-range` parameter is only consumed by the netpol (network policy) module for firewall RETURN rules. The proxy module never reads this configuration, creating a gap between administrator expectations and actual enforcement.\n\nKubernetes' `DenyServiceExternalIPs` Feature Gate was introduced in v1.22 and remains disabled by default through v1.31, meaning most clusters allow Services to carry externalIPs without any admission control.\n\n**Note:** This vulnerability class is not unique to kube-router. The upstream Kubernetes project classified the equivalent issue as [CVE-2020-8554](https://github.com/kubernetes/kubernetes/issues/97076) (CVSS 5.0/Medium), describing it as a design limitation with no planned in-tree fix. The reference service proxy (kube-proxy) and other third-party service proxy implementations exhibit the same behavior. kube-router's `--service-external-ip-range` parameter provides more defense-in-depth than most alternatives -- the gap is that this defense did not extend to the proxy module.\n\n## Details\n\n### Vulnerability Description\n\nKube-router's proxy module does not validate externalIPs or loadBalancer IPs before programming them into the node's network configuration:\n\n1. **Unconditional externalIPs copy**: `buildServicesInfo()` directly `copy()`s `Service.spec.ExternalIPs` without any range validation\n2. **Unconditional LoadBalancer IP trust**: The same function appends `status.loadBalancer.ingress[].ip` without verification\n3. **`--service-external-ip-range` not checked by proxy**: This parameter is only referenced in the netpol module, the proxy module never checks it\n4. **Cluster-wide impact**: IPs are bound to `kube-dummy-if` on all cluster nodes, added to IPVS, and added to the `kube-router-svip` ipset\n5. **No conflict detection**: ExternalIPs that overlap with existing ClusterIPs (e.g., kube-dns `10.96.0.10`) cause the legitimate IPVS real servers to be fully replaced by the attacker's endpoints during the stale-endpoint cleanup cycle, redirecting all traffic for that VIP:port to attacker-controlled pods\n\n### Vulnerable Code Locations\n\n**File**: `pkg/controllers/proxy/network_services_controller.go`\n\n**Lines 866, 898** - Unconditional externalIPs copy:\n```go\nexternalIPs: make([]string, len(svc.Spec.ExternalIPs)),\ncopy(svcInfo.externalIPs, svc.Spec.ExternalIPs) // No range check\n```\n\n**Lines 900-904** - Unconditional LoadBalancer IP trust:\n```go\nfor _, lbIngress := range svc.Status.LoadBalancer.Ingress {\n if len(lbIngress.IP) > 0 {\n svcInfo.loadBalancerIPs = append(svcInfo.loadBalancerIPs, lbIngress.IP)\n }\n}\n```\n\n**File**: `pkg/controllers/proxy/utils.go`\n\n**Lines 425-461** - `getAllExternalIPs()` merges IPs without range validation:\n```go\nfunc getAllExternalIPs(svc *serviceInfo, includeLBIPs bool) map[v1.IPFamily][]net.IP {\n // Only performs IP parsing and deduplication, no range checking\n}\n```\n\n**File**: `pkg/controllers/proxy/service_endpoints_sync.go`\n\n**Lines 460-464** - Binds arbitrary IPs to kube-dummy-if via netlink:\n```go\nerr = nsc.ln.ipAddrAdd(dummyVipInterface, externalIP.String(), nodeIP.String(), true)\n```\n\n**File**: `pkg/controllers/netpol/network_policy_controller.go`\n\n**Lines 960-967** - `--service-external-ip-range` is ONLY referenced here:\n```go\nfor _, externalIPRange := range config.ExternalIPCIDRs {\n _, ipnet, err := net.ParseCIDR(externalIPRange)\n npc.serviceExternalIPRanges = append(npc.serviceExternalIPRanges, *ipnet)\n}\n// The proxy module never references ExternalIPCIDRs\n```\n\n### Root Cause\n\nThe proxy module was implemented without externalIP range validation. The `--service-external-ip-range` parameter creates a gap between administrator expectations and actual enforcement: administrators may believe externalIPs are restricted to the configured range, but the proxy module (which actually configures IPVS and network interfaces) does not enforce this restriction.\n\nThis is consistent with the broader Kubernetes ecosystem. [CVE-2020-8554](https://github.com/kubernetes/kubernetes/issues/97076) documents the same fundamental issue: the Kubernetes API allows `Service.spec.externalIPs` to be set by any user with Service create/update permissions, and service proxies program these IPs into the data plane without validation. The upstream project's recommended mitigation is API-level admission control (e.g., `DenyServiceExternalIPs` feature gate, or admission webhooks).\n\n## PoC\n\n### Environment Setup\n\n```bash\n# Kind cluster: 1 control-plane + 1 worker\ncat > kind-config.yaml < /usr/share/nginx/html/index.html'\nkubectl --as=system:serviceaccount:attacker-ns:cicd-developer apply -f - < 0 {\n svcInfo.loadBalancerIPs = append(svcInfo.loadBalancerIPs, lbIngress.IP)\n }\n}\n```\n\n**File**: `pkg/controllers/proxy/utils.go`\n\n**Lines 425-461** - `getAllExternalIPs()` merges IPs without range validation:\n```go\nfunc getAllExternalIPs(svc *serviceInfo, includeLBIPs bool) map[v1.IPFamily][]net.IP {\n // Only performs IP parsing and deduplication, no range checking\n}\n```\n\n**File**: `pkg/controllers/proxy/service_endpoints_sync.go`\n\n**Lines 460-464** - Binds arbitrary IPs to kube-dummy-if via netlink:\n```go\nerr = nsc.ln.ipAddrAdd(dummyVipInterface, externalIP.String(), nodeIP.String(), true)\n```\n\n**File**: `pkg/controllers/netpol/network_policy_controller.go`\n\n**Lines 960-967** - `--service-external-ip-range` is ONLY referenced here:\n```go\nfor _, externalIPRange := range config.ExternalIPCIDRs {\n _, ipnet, err := net.ParseCIDR(externalIPRange)\n npc.serviceExternalIPRanges = append(npc.serviceExternalIPRanges, *ipnet)\n}\n// The proxy module never references ExternalIPCIDRs\n```\n\n### Root Cause\n\nThe proxy module was implemented without externalIP range validation. The `--service-external-ip-range` parameter creates a gap between administrator expectations and actual enforcement: administrators may believe externalIPs are restricted to the configured range, but the proxy module (which actually configures IPVS and network interfaces) does not enforce this restriction.\n\nThis is consistent with the broader Kubernetes ecosystem. [CVE-2020-8554](https://github.com/kubernetes/kubernetes/issues/97076) documents the same fundamental issue: the Kubernetes API allows `Service.spec.externalIPs` to be set by any user with Service create/update permissions, and service proxies program these IPs into the data plane without validation. The upstream project's recommended mitigation is API-level admission control (e.g., `DenyServiceExternalIPs` feature gate, or admission webhooks).\n\n## PoC\n\n### Environment Setup\n\n```bash\n# Kind cluster: 1 control-plane + 1 worker\ncat > kind-config.yaml < /usr/share/nginx/html/index.html'\nkubectl --as=system:serviceaccount:attacker-ns:cicd-developer apply -f - < 0 {\n svcInfo.loadBalancerIPs = append(svcInfo.loadBalancerIPs, lbIngress.IP)\n }\n}\n```\n\n**File**: `pkg/controllers/proxy/utils.go`\n\n**Lines 425-461** - `getAllExternalIPs()` merges IPs without range validation:\n```go\nfunc getAllExternalIPs(svc *serviceInfo, includeLBIPs bool) map[v1.IPFamily][]net.IP {\n // Only performs IP parsing and deduplication, no range checking\n}\n```\n\n**File**: `pkg/controllers/proxy/service_endpoints_sync.go`\n\n**Lines 460-464** - Binds arbitrary IPs to kube-dummy-if via netlink:\n```go\nerr = nsc.ln.ipAddrAdd(dummyVipInterface, externalIP.String(), nodeIP.String(), true)\n```\n\n**File**: `pkg/controllers/netpol/network_policy_controller.go`\n\n**Lines 960-967** - `--service-external-ip-range` is ONLY referenced here:\n```go\nfor _, externalIPRange := range config.ExternalIPCIDRs {\n _, ipnet, err := net.ParseCIDR(externalIPRange)\n npc.serviceExternalIPRanges = append(npc.serviceExternalIPRanges, *ipnet)\n}\n// The proxy module never references ExternalIPCIDRs\n```\n\n### Root Cause\n\nThe proxy module was implemented without externalIP range validation. The `--service-external-ip-range` parameter creates a gap between administrator expectations and actual enforcement: administrators may believe externalIPs are restricted to the configured range, but the proxy module (which actually configures IPVS and network interfaces) does not enforce this restriction.\n\nThis is consistent with the broader Kubernetes ecosystem. [CVE-2020-8554](https://github.com/kubernetes/kubernetes/issues/97076) documents the same fundamental issue: the Kubernetes API allows `Service.spec.externalIPs` to be set by any user with Service create/update permissions, and service proxies program these IPs into the data plane without validation. The upstream project's recommended mitigation is API-level admission control (e.g., `DenyServiceExternalIPs` feature gate, or admission webhooks).\n\n## PoC\n\n### Environment Setup\n\n```bash\n# Kind cluster: 1 control-plane + 1 worker\ncat > kind-config.yaml < /usr/share/nginx/html/index.html'\nkubectl --as=system:serviceaccount:attacker-ns:cicd-developer apply -f - <