Kubernetes unfixed CVEs: hardening guide for teams

On June 1, 2026, the Kubernetes Security Response Committee updated official CVE records for four long-running unfixed vulnerabilities: CVE-2020-8554, CVE-2020-8561, CVE-2020-8562, and CVE-2021-25740. The practical impact is easy to misread. This was not a surprise zero-day disclosure; it was a correction of records that previously implied fixes existed where Kubernetes actually depends on administrator-controlled mitigations.

CVE Summary Card

The official Kubernetes post, Reconciling the Past: Correcting Records for Unfixed Kubernetes CVEs, explains that some older CVE records had inaccurate fixed-version data. The project corrected those records on June 1, 2026, and the official Kubernetes CVE feed now reflects the updated state.

The common thread is trust delegation. Kubernetes exposes powerful primitives because controllers, load balancers, admission webhooks, and service discovery systems need them. In a single-team cluster, that may be acceptable. In a multi-tenant platform, those same primitives can become confused-deputy paths.

Vulnerable Code Anatomy

Service traffic ownership

CVE-2020-8554 is the clearest example. A tenant who can create or update a Service with spec.externalIPs can cause cluster traffic for that IP to route to their selected backend. A user with permission to patch status.loadBalancer.ingress.ip on a LoadBalancer Service can produce a similar result. The upstream issue states that all Kubernetes versions are affected and that the problem is a design flaw requiring user-facing changes.

The vulnerable pattern is not a buffer overflow or malformed packet parser. It is an API that assumes the user assigning a network address is authorized to own that address. That assumption collapses when namespaces represent different teams, customers, or trust zones.

Webhook redirects

CVE-2020-8561 centers on API server communication with admission webhooks. If an actor can configure an admission webhook endpoint, and the API server follows an HTTP redirect, the API server can be induced to make requests toward internal or otherwise sensitive networks. The risk is worse when verbose logging captures response bodies or when profiling can be used to alter behavior at runtime.

DNS consistency and proxying

CVE-2020-8562 is a time-of-check/time-of-use issue. The API server validates a resolved IP against restrictions, but the actual connection can resolve the same name again. If DNS answers differ between those two moments, a request can slip past intended IP filtering. Kubernetes documents the practical mitigation as DNS answer consistency, typically with a local caching resolver.

Endpoint authority

CVE-2021-25740 involves Endpoints and EndpointSlices. These objects describe the backend addresses behind Services. If a user can write them directly, they can point a Service, Ingress, or load-balancer path at addresses they should not expose. Kubernetes v1.22 removed this broad access from default aggregated edit and admin ClusterRoles for newly created clusters, but upgraded clusters may retain older permissions.

Attack Timeline

The timeline matters because many scanners and dashboards will make this feel like a sudden 2026 event. It is not.

1. December 4, 2020: Kubernetes issue #97076 documents CVE-2020-8554, a man-in-the-middle risk through LoadBalancer or ExternalIP behavior.
2. April 26, 2021: Kubernetes issue #101493 documents CVE-2020-8562, the API server proxy DNS race.
3. July 14, 2021: Kubernetes publishes the CVE-2021-25740 advisory for Endpoint and EndpointSlice cross-namespace forwarding.
4. Kubernetes v1.22: default RBAC for newly created clusters stops including broad Endpoint write access in aggregated roles as a mitigation for CVE-2021-25740.
5. May 14, 2026: Kubernetes announces v1.36 deprecation of Service .spec.externalIPs, with future removal planned no earlier than v1.40 for disabled support and v1.43 for complete disablement.
6. June 1, 2026: Kubernetes updates records for CVE-2020-8554, CVE-2020-8561, CVE-2020-8562, and CVE-2021-25740.

Exploitation Walkthrough

This section is intentionally conceptual. The point is to help defenders reason about blast radius without providing a working exploit chain.

Scenario 1: tenant controls Service routing

In a shared cluster, a tenant has permissions to create Services and pods in their namespace. If externalIPs is allowed, the tenant can request an IP that other workloads or nodes already treat as meaningful. Traffic meant for that IP can then be redirected to a backend the tenant controls. The defender should look for Services with unexpected externalIPs, unusual Service status patches, and audit events involving services/status.

Scenario 2: webhook redirect as an API server side channel

A user with authority to configure admission webhooks can point the API server at a webhook endpoint. If that endpoint redirects, the API server becomes the network client. The sensitive outcome is not arbitrary code execution; it is the API server being used as a requester into networks the user cannot directly reach, with logs becoming dangerous when verbosity is too high.

Scenario 3: DNS race in proxy validation

An attacker controls DNS answers for a hostname used in an API server proxy path. One answer satisfies validation, while a later answer points somewhere more sensitive. The exploitability depends on timing, permissions, DNS control, and network layout, which is why Kubernetes rates the issue low. The mitigation is still important because platform teams should not rely on DNS instability as a security boundary.

Scenario 4: Endpoint objects as confused deputies

A namespace user with Endpoint or EndpointSlice write access can define backends that do not correspond to pods they own. A load balancer, ingress controller, or internal service consumer may then forward traffic to those addresses under a trusted identity or network position. NetworkPolicy alone may not help if the trusted component is already allowed to reach the target.

Hardening Guide

Start with permissions and admission. These are the controls that turn architectural risk into a bounded operational surface.

1. Block Service externalIPs

Kubernetes documents DenyServiceExternalIPs as the built-in admission controller that rejects new use of the Service externalIPs field. Kubernetes v1.36 also formally deprecates the field. For most platform teams, the correct target state is simple: no tenant-authored externalIPs.

kube-apiserver \
  --enable-admission-plugins=DenyServiceExternalIPs

• Inventory existing Services with externalIPs before enforcing the admission controller.
• Migrate bare-metal use cases to a controlled LoadBalancer implementation such as MetalLB or to Gateway API.
• Do not grant ordinary users permission to patch services/status.

2. Reconcile Endpoint and EndpointSlice RBAC

For CVE-2021-25740, the critical audit is whether broad roles still include write verbs on Endpoints or EndpointSlices. This is especially important for clusters created before Kubernetes v1.22 and later upgraded.

kubectl auth can-i create endpoints --as=system:serviceaccount:team-a:default -n team-a
kubectl auth can-i patch endpointslices.discovery.k8s.io --as=system:serviceaccount:team-a:default -n team-a
kubectl get clusterrole -l rbac.authorization.k8s.io/aggregate-to-edit=true -o yaml

• Remove create, update, patch, and delete on Endpoints from general editor roles.
• Grant direct Endpoint writes only to controllers that require them.
• Review aggregated ClusterRoles because old labels can silently reintroduce privileges.

When documenting exceptions, sanitize hostnames, internal IP ranges, tokens, and customer identifiers before sharing evidence outside the platform team. TechBytes' Data Masking Tool is useful for cleaning audit excerpts and incident notes before they reach tickets, vendors, or postmortems.

3. Harden API server verbosity and profiling

For CVE-2020-8561, Kubernetes recommends keeping API server log verbosity below 10 and disabling dynamic profiling.

kube-apiserver \
  --v=2 \
  --profiling=false

• Verify managed-control-plane equivalents with your cloud provider rather than assuming flag-level access.
• Treat sudden verbosity increases as a security-relevant configuration drift.
• Restrict who can create or update admission webhook configurations.

4. Stabilize control-plane DNS

For CVE-2020-8562, the core mitigation is consistent DNS resolution between validation and connection. Kubernetes recommends a local caching resolver such as dnsmasq on control-plane nodes, with cache behavior tuned so repeated lookups return consistent answers across the request path.

• Prefer local resolver caching for API server egress paths.
• Monitor DNS answer churn for webhook and proxy-related hostnames.
• Avoid security policies that depend on DNS names resolving to stable private boundaries without enforcement below DNS.

5. Add detection that matches the abuse path

Do not stop at static configuration. Add audit and runtime signals that prove the mitigations keep working.

• Alert on Service creations or updates containing externalIPs.
• Alert on patch requests to services/status by human users or tenant service accounts.
• Alert on Endpoint or EndpointSlice writes outside trusted controller identities.
• Track admission webhook configuration changes as high-signal platform events.
• Use flow logs or eBPF telemetry to detect namespace traffic paths that bypass the expected service graph.

Architectural Lessons

The deeper lesson is that Kubernetes multitenancy cannot be secured by version upgrades alone. These CVEs persist because Kubernetes APIs were built to express infrastructure intent, and some intent is inherently privileged. A Service IP, a webhook endpoint, a proxy destination, and an EndpointSlice backend are all small fields with large authority.

Platform teams should draw sharper ownership boundaries around those fields:

• Network identity is privileged: IP assignment and load-balancer status should be controlled by platform-owned controllers, not arbitrary namespace users.
• Controller identity is a trust boundary: ingress controllers, admission webhooks, and service discovery controllers can become confused deputies.
• Default roles age badly: upgraded clusters need RBAC reconciliation because old aggregated roles can preserve pre-mitigation access.
• Scanner output is not policy: scanner findings should trigger control validation, not a blind search for a nonexistent patch.
• Architectural CVEs need runbooks: each unfixed CVE should map to a control owner, audit query, exception process, and regression test.

For 2026, the pragmatic target is not a zero-CVE Kubernetes cluster. It is a cluster where known architectural risks are explicitly owned, continuously checked, and denied by default for tenants. The corrected records make that obligation more visible. The hardening work was already due.