Kubernetes Improves CVE Transparency: Addressing Unfixed Vulnerabilities

The Kubernetes project emphasizes transparency to empower both cluster administrators and security researchers. A pivotal part of this initiative involves ensuring the accuracy of CVE records in the Common Vulnerabilities and Exposures database. Recently, discrepancies were identified in older records that incorrectly noted a fixed version for several unresolved issues.

According to the Kubernetes Security Response Committee (SRC), adjustments to these CVE records are scheduled for June 1, 2026. This change might lead to vulnerability scanners detecting these issues where they were previously overlooked.

To clarify the current situation, the following technical update addresses three significant vulnerabilities that have been disclosed in prior years yet still remain unfixed: CVE-2020-8561, CVE-2020-8562, and CVE-2021-25740.

Rationale for Updating CVE Records

Despite being publicly available for several years, the inadequacies in the CVE records were recently highlighted during the creation of official Open Source Vulnerabilities (OSV) files. It became clear that some records inaccurately suggested that a fixed version was available, whereas these vulnerabilities stem from architectural designs that cannot be fully resolved without disrupting core functionalities of Kubernetes.

Updating these records serves two main objectives:

• Accuracy in Automation: Modern vulnerability scanners rely on precise version definitions, and incorrect fixed tags could mislead users into thinking vulnerabilities are non-existent.
• Documenting Risks: By classifying these issues as unfixed, platform providers and administrators are made aware of the ongoing necessity for preventive measures.

It’s also important to point out that CVE-2020-8554 will not be overlooked; it is an unfixed CVE with the correct record indicating all versions are affected, and it will be updated to align with a more standardized version numbering system.

Review of Unfixed Architectural Vulnerabilities

The Kubernetes project will not resolve the following vulnerabilities, which remain communicated via respective GitHub issues outlining the technical intricacies involved:

CVE-2020-8561: Webhook Redirect in kube-apiserver

• Severity: Medium (4.1).
• The Issue: The kube-apiserver can follow HTTP redirects, which enables actors with configuration access to manipulate API server requests to internal networks.
• Why it remains unfixed: Addressing this would disrupt established HTTP client behavior that many existing integrations depend upon.
• Mitigation: Admins can adjust the API server log level to below 10 and disable dynamic profiling to prevent unauthorized changes.

CVE-2020-8562: Proxy Bypass via DNS TOCTOU

• Severity: Low (3.1).
• The Issue: A TOCTOU race condition in the API server proxy could allow users to bypass IP restrictions due to manipulation of DNS resolutions.
• Why it remains unfixed: Implementing a fix would require complex changes that might disrupt dynamic IP environments and split-horizon DNS.
• Mitigation: Administrators can deploy a local DNS caching server, like dnsmasq, on API server nodes to enforce response consistency.

CVE-2021-25740: Cross-Namespace Forwarding via Endpoints

• Severity: Low (3.1).
• The Issue: A flaw in the Endpoints and EndpointSlice APIs permits users to define IP addresses manually, potentially directing LoadBalancers or Ingress toward other namespaces.
• Why it remains unfixed: This capability is integral for many networking tools to function effectively.
• Mitigation: It's advisable to limit write permissions to Endpoints and EndpointSlices. From Kubernetes v1.22, these permissions are no longer included in the default RBAC roles, thus requiring review and adjustments for older clusters.

Actions for Administrators

The Kubernetes project advocates for a secure by configuration strategy for mitigating these persistent vulnerabilities:

The RBAC adjustment for CVE-2021-25740 is particularly relevant for clusters utilizing RBAC authorization mode, the standard for those created using conventional Kubernetes methods. It’s advisable for administrators to validate these configurations in test environments, evaluating the architectural risks against specific security requirements and tolerance levels.

Maturity Through Transparency

The initiative to amend these records underscores a maturation in the security landscape. By prioritizing accurate documentation over a solely "patch-only" mentality, the Kubernetes project equips the community with precise data needed for securing today’s cloud-native infrastructures.

Recognition is due to the security researchers—QiQi Xu, Javier Provecho, and others—who highlighted these issues, as well as the SIG Security Tooling contributors dedicated to refining these disclosures. Special thanks to Rory McCune for his insights surrounding these CVEs shared via his blog.

Update: On June 1, 2026, the Kubernetes SRC has amended the CVE records for CVE-2020-8554, CVE-2020-8561, CVE-2020-8562, and CVE-2021-25740.