EndpointSlice RBAC Hardening After CVE Corrections

On June 1, 2026, Kubernetes corrected CVE metadata for several older, unfixed issues. The EndpointSlice case, CVE-2021-25740, is the one platform teams should treat as an RBAC design review, not as a patch chase. The corrected record makes scanner output noisier, but the underlying risk is old: users who can write Endpoints or EndpointSlices may steer trusted load balancers or ingress controllers toward backends they should not expose.

CVE Summary Card

The official Kubernetes update says the Security Response Committee corrected the affected CVE records on June 1, 2026, after OSV feed work showed older records implied fixed versions where none existed. The project lists CVE-2021-25740 as a low-severity, CVSS 3.1 issue and states that all Kubernetes versions are affected because the behavior is tied to core Service networking semantics, not a narrow implementation bug.

• CVE: CVE-2021-25740
• Class: confused deputy through Service backend indirection
• Severity: low, CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:L/I:N/A:N
• Affected scope: all Kubernetes versions, per the corrected upstream record
• Primary mitigation: restrict write access to Endpoints and EndpointSlices

The practical change in 2026 is operational visibility. A scanner that previously suppressed the finding because it believed a later Kubernetes version was fixed can now report it again. That does not mean the cluster became newly exploitable on June 1, 2026. It means the metadata now matches the architectural reality documented by Kubernetes: this is a capability that must be governed by policy.

Vulnerable Code Anatomy

Why EndpointSlice exists

Endpoints and EndpointSlices describe where traffic for a Service should go. EndpointSlices were introduced to scale better than the original Endpoints object by splitting large backend sets into smaller objects. That scalability improvement also created a sharp authorization question: who is allowed to name backend addresses directly?

Most ordinary Services are selector-based. A controller observes Pods matching the Service selector and writes the corresponding endpoint data. The risky pattern appears when endpoint objects are manually managed, often for Services without selectors or for integrations that bridge Kubernetes traffic to something outside the normal Pod lifecycle.

apiVersion: v1
kind: Service
metadata:
  name: manually-backed-service
spec:
  ports:
  - port: 443
    targetPort: 443
  # No selector means endpoint data may be supplied by another actor.

This is not broken by itself. Kubernetes intentionally supports selectorless Services and manually managed endpoint data because operators, legacy systems, and network integrations need them. The vulnerability is that broad roles historically made endpoint writes look like ordinary application edit permission, even though writing endpoint data can influence where trusted network components send traffic.

The confused deputy

The deputy is usually a LoadBalancer, Ingress controller, or similar component that is already trusted by another namespace or network policy boundary. If an attacker can modify endpoint data for a Service the deputy will route to, the attacker may cause that deputy to connect to a backend that the attacker could not reach directly.

• Authorization gap: the attacker has Kubernetes API permission to update endpoint objects.
• Trust transfer: the networking component has access that the attacker does not.
• Policy bypass: NetworkPolicy may not help if it already trusts the load balancer or ingress path.
• Persistence: this remains possible until endpoint write permissions are narrowed.

The official Kubernetes issue is explicit that there is no patch for the issue and that mitigation is restriction of access to the vulnerable features. The Kubernetes CVE correction post adds the 2026 context: older CVE records suggested fixed versions, but the project now documents the issue as an unfixed architectural tradeoff.

Attack Timeline

The timeline matters because many teams will see this finding appear as if it were new. It is not new. The metadata correction changed how tooling reasons about it.

• July 14, 2021: Kubernetes issue #103675 was opened to track Endpoint and EndpointSlice cross-namespace forwarding.
• 2021 disclosure: the issue was assigned CVE-2021-25740 and rated low severity because exploitation requires authenticated API permissions and specific routing conditions.
• Kubernetes v1.22 era: default RBAC for new clusters stopped including Endpoint and EndpointSlice write permissions in the broad default edit/admin aggregation path.
• May 26, 2026: Kubernetes published the CVE reconciliation notice explaining that some old unfixed issues had incorrect fixed-version metadata.
• June 1, 2026: Kubernetes updated records for CVE-2020-8554, CVE-2020-8561, CVE-2020-8562, and CVE-2021-25740.

For upgraded clusters, the important nuance is inheritance. A cluster created before the default RBAC change can carry older permissions forward. A new cluster created on a later release may have safer defaults, but an upgraded cluster may still need manual reconciliation of system:aggregate-to-edit and related custom roles.

Exploitation Walkthrough

This walkthrough is conceptual and avoids a working exploit. The goal is to make the control boundary visible enough for defenders to test their own authorization model.

1. An authenticated user, service account, or compromised workload receives a broad role that allows create, update, or patch on Endpoints or EndpointSlices.
2. The attacker identifies a Service path consumed by a trusted ingress, gateway, or load balancer implementation.
3. The attacker changes endpoint data so the trusted component forwards traffic to a backend outside the intended namespace boundary.
4. The trusted component makes the network connection, so downstream policy sees traffic from an allowed infrastructure path rather than from the attacker.
5. The attacker gains exposure to a backend, metadata path, or internal service that should not have been reachable through their namespace permissions.

The exploitability depends on local design. A cluster with strict namespace tenancy, selector-only Services, and no broad endpoint writers has much less practical exposure. A multi-tenant cluster with shared ingress infrastructure and delegated namespace edit roles has a much more interesting attack surface.

Detection should focus on intent, not just object type. Endpoint controllers legitimately update these resources all day. Suspicious events are writes by human users, CI service accounts, or app workloads that do not own network control-plane duties. When sharing audit snippets in tickets or incident notes, redact user tokens, internal IPs, and tenant names; a simple privacy step with a Data Masking Tool prevents the remediation thread from becoming a secondary disclosure.

kubectl auth can-i update endpoints --as system:serviceaccount:team-a:default -n team-a
kubectl auth can-i update endpointslices.discovery.k8s.io --as system:serviceaccount:team-a:default -n team-a
kubectl get svc --all-namespaces -o=custom-columns='NAMESPACE:metadata.namespace,NAME:metadata.name,SELECTOR:spec.selector'

The first two checks ask whether a representative identity can write the risky resources. The third surfaces selectorless Services that deserve review because they may rely on manually supplied endpoint data.

Hardening Guide

Start with inventory

Before changing roles, map who can write endpoint resources and why. The fastest mistake is to remove permissions globally and break a legitimate controller that manages selectorless Services.

• List ClusterRoles and Roles granting write verbs on endpoints.
• List ClusterRoles and Roles granting write verbs on endpointslices in the discovery.k8s.io API group.
• Trace RoleBindings and ClusterRoleBindings to users, groups, and service accounts.
• Identify controllers that genuinely need endpoint writes and isolate them into purpose-built roles.

kubectl get clusterrole system:aggregate-to-edit -o yaml
kubectl auth reconcile --remove-extra-permissions -f aggregate_to_edit_no_endpoints.yaml --dry-run=client
kubectl auth reconcile --remove-extra-permissions -f aggregate_to_edit_no_endpoints.yaml

Kubernetes documents kubectl auth reconcile as the supported utility for creating or updating RBAC objects from a manifest, with --remove-extra-permissions removing permissions that are not present in the input. Use a dry run first, review the diff, and apply in a maintenance window if controllers depend on the current role shape.

Harden the default edit path

The upstream mitigation targets system:aggregate-to-edit because default edit/admin-style access is where many tenants historically inherited endpoint writes. For older clusters, Kubernetes originally recommended toggling the rbac.authorization.kubernetes.io/autoupdate annotation so reconciliation could apply the hardened role and then avoid restoring the old state.

• Remove endpoint write permissions from broad tenant roles.
• Do not grant * verbs on core API resources to application service accounts.
• Create a small controller-only Role for workloads that must manage selectorless Services.
• Use admission policy to block reintroduction of broad endpoint write rules.

OPA Gatekeeper’s library includes a policy named Block Endpoint Edit Default Role, which prevents system:aggregate-to-edit from granting create, patch, or update on endpoints. Treat that as a pattern, then extend it to your own role names and to EndpointSlices where your admission framework supports that check.

Monitor the right events

Audit logs should record endpoint writes with user identity, namespace, object name, and source. Alerting should be scoped enough to avoid noise from kube-controller-manager and known network controllers.

• Alert on endpoint writes by default service accounts.
• Alert on endpoint writes by human identities outside platform or networking groups.
• Review selectorless Services exposed through shared ingress or load balancer paths.
• Correlate endpoint changes with ingress reloads, gateway route changes, and unexpected backend connections.

Architectural Lessons

CVE-2021-25740 is a useful reminder that authorization is not only about API object ownership. Some objects are traffic-shaping objects. Granting write access to them can indirectly grant access to networks, tenants, and services that never appear in the role name.

• Model indirect authority: a user who controls a backend list may control where trusted infrastructure connects.
• Separate app edit from traffic control: namespace edit should not automatically include Service backend mutation.
• Prefer controller ownership: endpoint data should normally be produced by controllers with narrow service accounts.
• Baseline upgraded clusters: do not assume new defaults have rewritten old aggregated ClusterRoles.
• Read scanner changes carefully: a new finding can reflect better metadata rather than new exposure.

The deeper lesson from the June 2026 correction is that CVE metadata is part of the control plane for security operations. When records imply a fixed version, organizations encode that assumption into dashboards, exceptions, and risk acceptance workflows. When the record is corrected to say all versions are affected, the work shifts from patch management to configuration assurance.

That is the right framing for EndpointSlice RBAC hardening: make endpoint writes a privileged networking capability, keep broad edit roles focused on application lifecycle work, and verify the live authorization graph instead of relying on version numbers as a proxy for safety.