Kubernetes Unfixed CVE Records: What to Harden Now

On June 1, 2026, the Kubernetes Security Response Committee updated several older CVE records so scanners can correctly treat them as unfixed across all Kubernetes versions. That sounds worse than it is: these are not fresh remote-code-execution bugs. They are documented architectural risks in API server redirects, proxy DNS checks, Endpoints forwarding, and Service traffic interception that platform teams must harden through policy rather than waiting for a patch.

• CVE-2020-8561 depends on webhook control plus sensitive API server logging.
• CVE-2020-8562 is a DNS time-of-check/time-of-use proxy bypass risk.
• CVE-2021-25740 turns broad Endpoints write access into cross-namespace traffic forwarding.
• CVE-2020-8554 remains an unfixed Service externalIPs and LoadBalancer interception issue.
• Security teams should baseline scanner output after June 1, 2026, then verify controls.

CVE Summary Card

The official Kubernetes post Reconciling the Past: Correcting Records for Unfixed Kubernetes CVEs explains the immediate reason for the June update: Open Source Vulnerability file generation exposed CVE metadata that implied fixed versions existed when they did not. The project corrected those records so automation can stop producing false negatives.

The shared pattern is that Kubernetes is preserving compatibility for legitimate extensibility points. Admission webhooks, API server proxying, manually managed Endpoints, and flexible Service routing are all powerful features. The vulnerability appears when those features are delegated too broadly or run without compensating controls.

Vulnerable Code Anatomy

Webhook redirect behavior

CVE-2020-8561 lives in the interaction between the kube-apiserver and admission webhooks. A user who can influence a MutatingWebhookConfiguration or ValidatingWebhookConfiguration response path may cause the API server's HTTP client to follow a redirect toward an internal network target. The problem is amplified when API server logs include response data.

• The dangerous permission is not ordinary pod creation; it is control over admission webhook configuration or its response infrastructure.
• The dangerous observability setting is API server verbosity at --v=10, because response bodies can become visible in logs.
• The dangerous runtime setting is --profiling=true where it permits dynamic log-level changes by authorized actors.

Proxy DNS time-of-check gap

CVE-2020-8562 is subtler. Kubernetes added checks to stop user-driven proxy connections from reaching loopback and link-local targets such as 127.0.0.0/8 and 169.254.0.0/16. The flaw is that a DNS name can be resolved once for validation and resolved again for the actual connection. If a DNS server gives different answers, the second answer can undermine the first check.

This is why the mitigation is not a Kubernetes patch. Pinning DNS answers inside the API server risks breaking split-horizon DNS and highly dynamic environments. A caching resolver close to the control plane reduces the race without changing API semantics.

Endpoints as an authority boundary

CVE-2021-25740 is a confused-deputy issue around Endpoints and EndpointSlices. These APIs allow explicit backend IPs. That is useful for migration, service discovery integrations, and custom controllers, but it becomes dangerous when a tenant can point a Service, LoadBalancer, or Ingress at backends it should not reach.

Kubernetes changed default RBAC behavior in v1.22 so the default edit and admin ClusterRoles no longer include broad write access to those resources for newly created clusters. Clusters upgraded from older releases may still carry aggregated permissions and need manual review.

Attack Timeline

A realistic timeline starts with access, not memory corruption. None of these records describes an unauthenticated internet exploit against a default control plane. They describe what happens after a user, workload identity, controller, or compromised automation path has the wrong platform-level permission.

1. Initial foothold: an attacker obtains credentials for a tenant, CI job, controller service account, or operator account.
2. Capability discovery: the attacker checks whether the identity can modify webhook configuration, Nodes, StorageClasses, Services, Endpoints, or EndpointSlices.
3. Control-plane interaction: the attacker attempts to route an allowed Kubernetes feature toward a target the identity should not directly access.
4. Signal collection: the attacker looks for API server logs, controller-manager logs, traffic responses, or service behavior that reveal private data.
5. Persistence or lateral movement: if the feature works, the attacker repeats it through automation or a hidden controller path.

The record correction matters because vulnerability tools often key off affected and fixed version ranges. If a record wrongly says a fix exists, a scanner may suppress the finding on newer clusters. After June 1, 2026, teams should expect older Kubernetes architecture findings to reappear and should map them to controls instead of chasing phantom upgrade targets.

Exploitation Walkthrough

This walkthrough is conceptual only. It describes the trust-boundary failure patterns so defenders can reason about exposure without providing a working proof of concept.

CVE-2020-8561: redirect plus log visibility

• An actor gains the ability to influence an admission webhook endpoint or configuration.
• The API server contacts that webhook as part of normal admission processing.
• The webhook interaction redirects the API server toward a private address reachable from the control plane.
• If verbose logging is enabled, response data may land in API server logs that the actor can read.

The defensive question is simple: who can configure webhooks, who can run the backing endpoint, and who can read control-plane logs? For regulated environments, sanitize any copied investigation material before sharing it in tickets or chat; TechBytes' Data Masking Tool is useful for redacting tokens, hostnames, and customer identifiers in incident notes.

CVE-2020-8562: DNS inconsistency

• An authorized actor triggers a proxy path involving a DNS name.
• The validation lookup returns an allowed address.
• The connection lookup returns a different address, potentially in a restricted range.
• The actor attempts to infer private control-plane network information from the resulting behavior or logs.

The platform lesson is that validation and use must share the same view of name resolution. Since Kubernetes cannot safely impose that on every environment, control-plane DNS should.

CVE-2021-25740 and CVE-2020-8554: traffic steering

• An actor obtains write access to traffic-routing resources.
• The actor points a Kubernetes abstraction at an IP or backend outside the expected namespace or ownership boundary.
• Load balancing, ingress, or Service routing forwards traffic through a path that appears legitimate to infrastructure.
• The attacker uses the feature as an unintended network bridge rather than as a direct code exploit.

This is why permissions around networking resources deserve the same scrutiny as permissions around Secrets. A user who can create a benign-looking object that changes traffic paths may own a much larger blast radius than the namespace name suggests.

Hardening Guide

1. Normalize the scanner event

Start by treating the post-June results as a metadata correction. Update your vulnerability exception language to say these are unfixed Kubernetes architectural CVEs with configuration mitigations. Avoid exceptions that say the issue is not applicable merely because the cluster is new.

• Record the cluster version and scanner version used for the baseline.
• Map each finding to a control owner: API server flags, DNS, RBAC, or Service admission policy.
• Attach official references from Kubernetes and the relevant GitHub issue to each risk entry.

2. Lock down kube-apiserver observability risk

For CVE-2020-8561, verify the API server is not running at unsafe verbosity and that profiling is disabled where your operational model allows it.

kube-apiserver:
  args:
    - --v=2
    - --profiling=false

• Keep --v below 10 for production API servers.
• Set --profiling=false unless you have a documented, access-controlled profiling workflow.
• Restrict read access to control-plane component logs.
• Audit who can create or update MutatingWebhookConfiguration and ValidatingWebhookConfiguration.

3. Stabilize control-plane DNS

For CVE-2020-8562, place a caching resolver on or near the control-plane nodes and configure a minimum cache TTL appropriate for your environment. The Kubernetes recommendation names dnsmasq as an example; the important property is consistent answers between validation and connection.

• Document which resolver the API server and controller-manager use.
• Test split-horizon domains before changing production resolver behavior.
• Monitor for control-plane requests to loopback and link-local ranges.

4. Reconcile Endpoints and EndpointSlices RBAC

For CVE-2021-25740, focus on upgraded clusters and aggregated ClusterRoles. Kubernetes v1.22 removed broad Endpoints and EndpointSlices write access from default edit and admin ClusterRoles for new clusters, but upgrades can preserve old grants.

• List identities that can create, patch, or update Endpoints and EndpointSlices.
• Remove those verbs from tenant-facing roles unless a controller explicitly requires them.
• Prefer controller-specific service accounts over human or namespace-wide grants.
• Use admission policy to restrict manually specified backend IP ranges.

5. Govern Service fields that steer traffic

CVE-2020-8554 is the oldest warning in this set, but it remains operationally important. Treat externalIPs, LoadBalancer behavior, and related Service routing fields as privileged networking operations, not as harmless app configuration.

• Block or gate externalIPs for ordinary namespaces.
• Require review for Services that route to shared, private, or control-plane-adjacent address ranges.
• Prefer Gateway API or cloud-provider controls that make ownership explicit.

Architectural Lessons

The uncomfortable lesson is that Kubernetes cannot patch every security boundary without breaking the reason many teams use Kubernetes: extensibility. The API server follows HTTP behavior that integrations expect. DNS can be dynamic. Endpoints can represent non-pod backends. Services can intentionally abstract traffic. Removing all sharp edges would strand real production patterns.

Platform teams therefore need a different operating model for unfixed CVEs:

• Version upgrades are necessary but insufficient: keep clusters current, but do not assume a newer minor release removes architectural risks.
• RBAC is part of network security: permissions to write routing objects can be equivalent to permissions to reach networks.
• Control-plane logs are sensitive data: verbose debugging settings can turn low-severity routing bugs into useful information disclosure paths.
• Scanner policy needs nuance: unresolved does not mean unmitigated, and old does not mean irrelevant.
• Compatibility has a security cost: when Kubernetes preserves behavior for operators and integrations, platform teams must narrow who can invoke that behavior.

The practical finish line is not a clean scanner dashboard. It is an evidence-backed exception that says: the CVE affects all versions, our cluster exposes or does not expose the prerequisite capability, and these controls reduce the residual risk. That is the difference between suppressing a finding and actually owning it.