CVE-2021-25736: Kubernetes Information Disclosure Flaw

CVE-2021-25736 Overview

CVE-2021-25736 affects the Kubernetes kube-proxy component running on Windows nodes. The flaw allows unintended forwarding of network traffic to local processes listening on the same TCP/UDP port as a LoadBalancer Service. Exploitation requires that the LoadBalancer controller does not populate the status.loadBalancer.ingress[].ip field for the Service. Clusters where the controller correctly sets this field are not impacted.

The issue is tracked under [CWE-114] (Process Control) and impacts the confidentiality of traffic flowing through Windows-based Kubernetes data planes. The vulnerability was disclosed through the Kubernetes security announcement process and addressed via upstream patches.

Critical Impact
An attacker with low privileges on the network can intercept or receive traffic intended for a LoadBalancer Service backend, exposing sensitive data flowing through Windows kube-proxy instances.

Affected Products

Kubernetes (versions prior to the patched releases referenced in the Kubernetes security announcement)
Microsoft Windows nodes running kube-proxy
Downstream distributions including NetApp products that ship Kubernetes components

Discovery Timeline

2023-10-30 - CVE-2021-25736 published to NVD
2025-06-12 - Last updated in NVD database

Technical Details for CVE-2021-25736

Vulnerability Analysis

The defect resides in the Windows implementation of kube-proxy, the network proxy that maintains Service abstractions on each node. When a Kubernetes Service of type LoadBalancer is created, kube-proxy installs forwarding rules so that traffic arriving at the load balancer ingress IP reaches the correct pods.

On Windows nodes, kube-proxy evaluates the Service spec.ports[*].port value when programming these rules. If the upstream LoadBalancer controller never populates status.loadBalancer.ingress[].ip, kube-proxy falls back to a code path that can match any traffic destined to that port on the node. As a result, traffic intended for the Service can be redirected to unrelated local processes that happen to bind the same port.

Root Cause

The root cause is improper validation of the LoadBalancer Service state before installing port-level forwarding rules. The Windows kube-proxy code did not require a populated status.loadBalancer.ingress[].ip field before programming HNS (Host Networking Service) policies tied to spec.ports[*].port. This omission allowed local listeners to receive traffic that should have been scoped to the load balancer ingress endpoint, aligning with [CWE-114] process-control weaknesses.

Attack Vector

Exploitation requires an attacker who can run a process on a Windows worker node and bind to the same port number declared in a LoadBalancer Service spec.ports[*].port. Once bound, the attacker's process can receive traffic that legitimate clients send to the Service. The attack vector is network-based with high complexity, because it depends on cluster configuration in which the LoadBalancer controller does not set the ingress IP status field. No user interaction is required. See the upstream fix in the Kubernetes Pull Request #99958 for the implementation change that scopes forwarding to the validated ingress IP.

Detection Methods for CVE-2021-25736

Indicators of Compromise

Unexpected processes on Windows nodes binding to ports listed in LoadBalancer Service spec.ports[*].port definitions.
Service traffic terminating at a local process rather than the intended backend pod, observable through application logs or session anomalies.
LoadBalancer Service objects whose status.loadBalancer.ingress[].ip field is empty while traffic is still flowing through kube-proxy.

Detection Strategies

Audit all Service objects of type LoadBalancer and flag any with an empty status.loadBalancer.ingress array.
Inventory listening sockets on Windows worker nodes using netstat -ano and correlate against Service port declarations.
Review HNS policy configurations on Windows nodes to confirm forwarding rules reference a valid ingress IP, not only a port.

Monitoring Recommendations

Forward Kubernetes audit logs and Windows network telemetry to a centralized analytics platform for correlation across nodes.
Alert when a non-system process on a Windows node binds to a port that matches a published Service port.
Monitor kube-proxy version and configuration drift across the cluster to ensure all Windows nodes run patched builds.

How to Mitigate CVE-2021-25736

Immediate Actions Required

Upgrade kube-proxy on all Windows nodes to a Kubernetes release that includes the fix from Kubernetes PR #99958.
Verify that the LoadBalancer controller in use populates status.loadBalancer.ingress[].ip for every Service of type LoadBalancer.
Review and restrict which workloads and users can create privileged listeners on Windows nodes.

Patch Information

The Kubernetes project addressed CVE-2021-25736 in upstream releases referenced by the Kubernetes Security Announcement. Downstream vendors including NetApp issued coordinated advisories; see the NetApp Security Advisory NTAP-20231221-0003 for distribution-specific guidance. Operators should apply the patched kube-proxy binary to all Windows nodes and confirm the deployment with kubectl get nodes -o wide and kube-proxy --version.

Workarounds

Configure the LoadBalancer controller to always populate status.loadBalancer.ingress[].ip so that kube-proxy programs forwarding rules scoped to a specific IP.
Avoid scheduling untrusted workloads on Windows nodes that host LoadBalancer Service backends.
Use network policies and host-level firewall rules on Windows nodes to prevent unauthorized processes from binding to Service ports.

bash

# Verify LoadBalancer Services have ingress IP populated
kubectl get svc --all-namespaces -o jsonpath='{range .items[?(@.spec.type=="LoadBalancer")]}{.metadata.namespace}{"/"}{.metadata.name}{" ingress="}{.status.loadBalancer.ingress}{"\n"}{end}'

# Check kube-proxy version on Windows nodes
kubectl get nodes -l kubernetes.io/os=windows -o jsonpath='{range .items[*]}{.metadata.name}{" "}{.status.nodeInfo.kubeProxyVersion}{"\n"}{end}'