Kubernetes Unfixed CVE Records: Hardening Guide [2026]

On June 1, 2026, the Kubernetes Security Response Committee corrected records for older vulnerabilities that were never actually fixed in code. The practical impact is immediate for platform teams: scanners may newly report CVE-2020-8561, CVE-2020-8562, and CVE-2021-25740 even on current clusters, while CVE-2020-8554 remains an already-known unfixed architectural risk. Treat these as control-plane hardening findings, not routine patch backlog.

CVE Summary Card

The upstream Kubernetes post, Reconciling the Past: Correcting Records for Unfixed Kubernetes CVEs, explains that official OSV generation exposed incorrect fixed-version metadata. The records previously implied that fixed releases existed. Kubernetes now states that these issues are architectural trade-offs that cannot be fully remediated without breaking expected behavior.

For inventory work, pull from the official Kubernetes CVE feed instead of scraping scanner text. If your triage artifacts include cluster names, namespaces, service names, or internal DNS zones, sanitize exports before sharing them externally; TechBytes' Data Masking Tool is useful for removing operational identifiers from tickets and postmortems.

Vulnerable Code Anatomy

Webhook redirects and log exposure

CVE-2020-8561 lives at the boundary between API extensibility and control-plane trust. Admission webhooks are intentionally allowed to receive API admission requests from kube-apiserver. The risky behavior is that the HTTP client can follow redirects when a webhook endpoint responds with one. If an actor can control a MutatingWebhookConfiguration or ValidatingWebhookConfiguration, the API server may be induced to request an internal target reachable from the control plane.

The sensitive part is not merely the outbound request. The Kubernetes advisory says exposure depends on logging: if API server verbosity reaches --v=10, response bodies and headers can become visible in logs. That turns a routing quirk into a confidentiality issue when the actor can also read kube-apiserver process logs.

DNS check/use split in proxy paths

CVE-2020-8562 is a classic time-of-check to time-of-use problem. Kubernetes validates DNS resolution to avoid link-local or localhost addresses, then later performs a second resolution for the actual connection. With a non-standard DNS server returning different answers between those two moments, the control plane may make a proxied connection that bypasses the intended IP restriction.

This exists because pinning the first resolved IP sounds clean in isolation but can break real split-horizon DNS, service discovery, and dynamic infrastructure patterns. Kubernetes therefore documents caching DNS as the practical mitigation instead of promising a universal code fix.

Endpoints as a routing authority

CVE-2021-25740 is about who gets to name backends. Endpoints and EndpointSlices can contain manually specified IP addresses. If a user can edit those objects, they may be able to point a Service, LoadBalancer, or Ingress path at a backend outside the namespace boundary the user was supposed to operate within.

This is why the fix is authorization, not a patch. The object model permits manual endpoint management because many controllers and networking tools rely on it. Platform teams must separate ordinary application editing from backend routing authority.

Attack Timeline

The June 2026 event is best understood as a metadata timeline, not an exploit release timeline.

1. 2020-2021: The underlying vulnerabilities are disclosed and assigned CVE identifiers.
2. 2021: GitHub issues for CVE-2020-8561, CVE-2020-8562, and CVE-2021-25740 document that all versions are affected and no code fix exists at that time.
3. Kubernetes v1.22: Default RBAC for new clusters stops including Endpoints and EndpointSlices write permissions in the default edit and admin aggregate roles, reducing exposure for newly created clusters.
4. May 26, 2026: Kubernetes announces the planned CVE record correction after official OSV feed work finds inaccurate fixed-version fields.
5. June 1, 2026: The Kubernetes SRC updates records for CVE-2020-8554, CVE-2020-8561, CVE-2020-8562, and CVE-2021-25740.
6. June 12, 2026: The official CVE feed shows current records and scanners may now raise findings that looked absent before.

Exploitation Walkthrough

This walkthrough is conceptual only. It intentionally avoids payloads, working manifests, and commands that would reproduce the issues.

CVE-2020-8561 concept

• An attacker needs high privilege: the ability to influence admission webhook configuration or the webhook response path.
• The attacker arranges for the API server's webhook request to receive an HTTP redirect toward an internal control-plane-reachable destination.
• If API server logs are readable and verbosity is dangerously high, sensitive response data may appear in logs.
• The strongest practical controls are reducing log verbosity, disabling dynamic profiling, and limiting who can configure admission webhooks.

CVE-2020-8562 concept

• An authorized user interacts with API server proxy behavior that performs DNS validation before making a connection.
• A DNS service returns one answer at validation time and a different answer when the connection is made.
• The second answer may route the request to a private address that should have been blocked.
• A caching resolver narrows the race by forcing consistent answers across the validation and connection phases.

CVE-2021-25740 concept

• A user with write access to Endpoints or EndpointSlices modifies backend IPs for a Service-like path.
• A LoadBalancer or Ingress implementation trusts those backend records as routing data.
• Traffic is forwarded to a location outside the namespace trust boundary.
• NetworkPolicy may not save you if the trusted load balancer or ingress path is the confused deputy.

Hardening Guide

Start with a finding owner model. These CVEs cross security, platform, and networking boundaries, so a scanner ticket assigned only to an application team will stall. The platform team should own baseline controls, while service teams own application-specific endpoint exceptions.

1. Normalize scanner triage

• Mark CVE-2020-8561, CVE-2020-8562, and CVE-2021-25740 as unfixed architectural risks in your vulnerability management system.
• Do not suppress them globally. Attach evidence that the cluster-level mitigation exists.
• Track exceptions by cluster, control-plane profile, and tenant model.
• Reference the official Kubernetes CVE feed in the ticket so future audits do not depend on vendor-specific scanner wording.

2. Lock down kube-apiserver logging and profiling

For CVE-2020-8561, validate that API server verbosity is below 10 and profiling is disabled where your provider permits it.

# Audit intent only; adapt to your control-plane deployment model
# Check static pod manifests, managed cluster settings, or provider policy for:
--v=<value less than 10>
--profiling=false

• Keep --v below 10 on production control planes.
• Set --profiling=false to prevent dynamic log-level manipulation through profiling endpoints.
• Restrict access to API server logs to the smallest operational group that needs them.
• Review log aggregation pipelines for accidental exposure of headers or response bodies.

3. Stabilize control-plane DNS resolution

For CVE-2020-8562, the mitigation is not a Kubernetes flag. It is consistent DNS behavior for the API server during validation and connection. The upstream issue specifically calls out dnsmasq with low non-zero min-cache-ttl and neg-ttl values as one mitigation pattern.

• Run a caching resolver on control-plane nodes or use an equivalent provider-supported resolver path.
• Confirm that proxy-related control-plane lookups do not receive intentionally inconsistent answers.
• Monitor Kubernetes API audit logs for proxied calls and denied address attempts.
• Document any split-horizon DNS dependencies before changing cache behavior.

4. Reconcile Endpoints and EndpointSlice RBAC

For CVE-2021-25740, upgraded clusters deserve special attention. Kubernetes says clusters created with v1.22 or later have safer default aggregate roles, but clusters upgraded from older releases may retain broader permissions.

# Discovery: find broad grants that include Endpoints or EndpointSlices writes
kubectl get clusterrole -o json | jq '.items[] | {name: .metadata.name, rules: .rules}'

# Service inventory: identify Services with empty selectors for review
kubectl get svc --all-namespaces -o=custom-columns='NAME:metadata.name,NAMESPACE:metadata.namespace,SELECTOR:spec.selector'

• Remove broad create, update, and patch permissions on endpoints and endpointslices.
• Create purpose-built Roles only for controllers that truly manage those objects.
• Audit Services without selectors because they often rely on manually managed endpoint records.
• Verify Ingress controller behavior around ExternalName Services and disable unsafe forwarding options where available.

5. Add admission policy around risky routing fields

For CVE-2020-8554 and the endpoint-forwarding class of issues, admission control is the durable guardrail. Use policy to restrict who can set Service fields that influence traffic interception or cross-boundary routing. The exact implementation may be ValidatingAdmissionPolicy, a policy engine, or a managed-provider control, but the principle is the same: routing authority must be explicit.

Architectural Lessons

The important lesson is that Kubernetes security is not only patch velocity. Some risks sit in the contract between APIs, controllers, and operators. Removing the feature would break real clusters; leaving it unconstrained creates confused-deputy paths. Mature platform engineering treats those cases as product decisions with controls, ownership, and evidence.

• Extensibility needs privilege boundaries. Admission webhooks, custom endpoints, and proxy paths are power tools, not application defaults.
• Scanner truth depends on upstream metadata quality. The 2026 correction improves automation even though it creates noisy first-week dashboards.
• RBAC defaults help new clusters but do not automatically repair every upgraded cluster.
• NetworkPolicy is not a universal boundary when a trusted controller forwards traffic on behalf of another user.
• Security exceptions should expire only when architecture changes, not when the same unfixed CVE disappears from one vendor feed.

The practical next step is a short hardening sprint: prove API server log and profiling posture, enforce stable control-plane DNS, reconcile endpoint write permissions, and encode routing-risk policy in admission. Once those controls are in place, these CVEs become managed architectural debt instead of recurring scanner surprises.