EndpointSlice RBAC Hardening After CVE Fix Corrections

On June 1, 2026, the Kubernetes Security Response Committee updated older CVE records so scanners stop treating several architectural risks as fixed-by-version bugs. For platform teams, the most operationally important one is CVE-2021-25740: write access to Endpoints and EndpointSlices can let a low-privileged user route traffic across namespace boundaries through trusted ingress or load-balancer paths. The fix is not a patch train. It is RBAC evidence, narrow delegation, and repeatable drift detection.

CVE Summary Card

The metadata correction matters because it changes how risk appears in tools. The official Kubernetes blog says the affected records were corrected on June 1, 2026, after OSV feed work exposed records that incorrectly suggested fixed versions. The CVEs are old, but the scanner behavior is new: findings may appear in environments that have been patched for years because the issue is not version-remediated.

• CVE: CVE-2021-25740.
• Severity: Low, CVSS 3.1 score 3.1.
• Component: Kubernetes API objects used by Services and network implementations.
• Affected versions: all Kubernetes versions, according to the original advisory.
• Primary mitigation: restrict write access to Endpoints and EndpointSlices.

The authoritative threads are worth bookmarking: the Kubernetes record-correction post at kubernetes.io, the RBAC documentation for EndpointSlice write access at kubernetes.io, and the original CVE-2021-25740 advisory issue.

Vulnerable Code Anatomy

Where the weakness lives

This is not a memory safety bug, parser bug, or missed bounds check. The vulnerable surface is the legitimate data model around Service backends. Kubernetes allows a Service without a selector to be paired with explicitly managed endpoint resources. That feature supports external backends, migration patterns, service meshes, and controllers that synthesize endpoints outside the normal Pod selector flow.

The risky shape is simple:

• A user can create or update a Service-facing backend object.
• An ingress controller, load balancer, or internal proxy trusts that backend object.
• The backend address points somewhere the user should not normally reach.
• Traffic flows through a trusted network component, bypassing namespace-level expectations.

EndpointSlice made endpoint representation more scalable, but it did not remove the trust problem. The object can still describe network addresses. Once a privileged network component consumes those addresses, enforcement depends on how that component validates, filters, and reaches them.

Why NetworkPolicy is not enough

The original advisory explicitly calls out the confused deputy pattern: if the target already trusts the ingress or load-balancer implementation, a namespace-level NetworkPolicy may not block the forwarded path. The attacker is not necessarily connecting directly from their pod to the target. They are persuading an already-trusted component to connect on their behalf.

Attack Timeline

The timeline is useful because it explains why teams are seeing fresh vulnerability pressure from an old advisory.

1. July 14, 2021: Kubernetes publishes CVE-2021-25740, describing cross-namespace forwarding through Endpoints and EndpointSlices.
2. Kubernetes v1.22: new clusters created with RBAC defaults no longer include the relevant broad write permissions in the default edit and admin aggregation path.
3. 2021-2026: upgraded clusters, copied roles, vendor defaults, and hand-written platform roles can retain or reintroduce endpoint write access.
4. May 26, 2026: Kubernetes announces that several older CVE records contained incorrect fixed-version metadata.
5. June 1, 2026: Kubernetes SRC updates records for CVE-2020-8554, CVE-2020-8561, CVE-2020-8562, and CVE-2021-25740.
6. After June 1, 2026: scanners can begin flagging clusters or packages that were previously hidden behind inaccurate fixed-version data.

The practical change is governance, not exploit novelty. Security teams need a different closure artifact: a patch version is insufficient; an RBAC diff, exception register, and controller inventory are stronger evidence.

Exploitation Walkthrough

Conceptual path only

A realistic exploitation chain starts with a principal that has more namespace power than it should. That could be a developer role, CI service account, compromised workload identity, or automation token. The critical permission is write access to endpoint resources, especially when combined with the ability to create a selectorless Service or influence an ingress route.

Conceptually, the attack looks like this:

1. The attacker identifies a network component that forwards to Service backends.
2. The attacker creates or modifies backend metadata in their namespace.
3. The backend metadata references an address outside the namespace boundary the attacker is supposed to operate within.
4. The trusted ingress or load-balancer implementation accepts the backend and initiates traffic.
5. The target sees traffic from trusted infrastructure instead of the attacker's pod identity.

This walkthrough deliberately avoids a working manifest. The important engineering lesson is that the API server may accept semantically valid endpoint data while the surrounding architecture treats that data as more trustworthy than the submitting identity deserves.

Signals worth investigating

• Services with no selector in application namespaces.
• Unexpected EndpointSlice writers outside platform networking controllers.
• Ingress routes that can target selectorless Services.
• Roles granting create, update, or patch on endpoint resources to broad groups.
• Recent changes by CI identities that normally should only deploy workloads.

When exporting audit evidence for review, redact service account tokens, internal hostnames, and customer namespace names before sharing. A small hygiene step such as passing snippets through TechBytes' Data Masking Tool helps keep remediation notes useful without leaking sensitive topology.

Hardening Guide

Audit effective permissions

Start with the identities that can change production routing. The goal is to find who can write endpoints in the core API group and endpointslices in discovery.k8s.io.

kubectl auth can-i create endpoints --as=system:serviceaccount:app:deployer -n app
kubectl auth can-i patch endpointslices.discovery.k8s.io --as=system:serviceaccount:app:deployer -n app
kubectl get clusterroles -o yaml | grep -n "endpointslices\|endpoints"

For fleet checks, prefer structured parsing over one-off text inspection. Export roles as JSON, evaluate rules by API group, resource, and verb, then keep the report as audit evidence.

Reconcile legacy aggregate roles

The Kubernetes advisory recommends using kubectl auth reconcile to remove extra endpoint write permissions from the broad aggregate edit role in affected clusters. Test this first in a non-production cluster that mirrors your RBAC customizations.

# From the Kubernetes advisory workflow: test first, then apply deliberately.
kubectl annotate --overwrite clusterrole/system:aggregate-to-edit rbac.authorization.kubernetes.io/autoupdate=true
kubectl auth reconcile --remove-extra-permissions -f aggregate_to_edit_no_endpoints.yaml.txt --dry-run
kubectl auth reconcile --remove-extra-permissions -f aggregate_to_edit_no_endpoints.yaml.txt
kubectl annotate --overwrite clusterrole/system:aggregate-to-edit rbac.authorization.kubernetes.io/autoupdate=false

That workflow is powerful because --remove-extra-permissions changes authorization behavior. Treat it like a production migration:

• Inventory workloads that depend on selectorless Services.
• Identify controllers that legitimately manage endpoint resources.
• Create purpose-built Roles for those controllers instead of restoring broad edit access.
• Run admission tests for ingress, service mesh, and load-balancer controllers.
• Record every exception with owner, namespace, reason, and expiry date.

Use purpose-built endpoint writer roles

Most application deployers do not need endpoint write access. If a controller genuinely owns endpoint materialization, bind that permission to its service account and namespace only.

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: endpoint-writer-for-controller
  namespace: platform-networking
rules:
- apiGroups: [""]
  resources: ["endpoints"]
  verbs: ["get", "list", "watch", "create", "update", "patch"]
- apiGroups: ["discovery.k8s.io"]
  resources: ["endpointslices"]
  verbs: ["get", "list", "watch", "create", "update", "patch"]

Do not copy that Role into developer namespaces as a convenience. Its value is in narrow binding, controller ownership, and reviewability.

Add admission and monitoring guardrails

• Reject endpoint writes from non-controller service accounts unless an exception label is approved.
• Alert on selectorless Services created outside approved namespaces.
• Alert when an EndpointSlice address targets sensitive internal ranges defined by your threat model.
• Log changes to endpoint resources at a level your SIEM can retain and search.
• Test ingress and load-balancer implementations for ExternalName and selectorless Service behavior.

Architectural Lessons

CVE-2021-25740 is a reminder that Kubernetes security often fails at composition boundaries. A resource can be valid, an ingress controller can be behaving as configured, and a NetworkPolicy can still express the wrong trust assumption. The bug is the gap between identity, intent, and forwarding authority.

• Authorization must follow consequences: endpoint writes are routing authority, not ordinary deployment metadata.
• Defaults age differently on upgraded clusters: a cluster born before v1.22 can carry older assumptions indefinitely.
• Scanner accuracy changes workload: metadata corrections create operational tasks even when the exploit did not change.
• Exceptions need owners: selectorless Services are valid, but anonymous exceptions become permanent attack surface.
• Network controls need identity context: if trusted infrastructure forwards traffic, policy must account for delegated reachability.

The mature response is to stop asking, "Which Kubernetes version fixed this?" and start asking, "Which identities can alter the routing graph?" Once endpoint writes are treated as privileged networking operations, the mitigation becomes straightforward: remove broad grants, bind narrow controller roles, monitor drift, and document the remaining exceptions.