Four older Kubernetes CVEs (CVE-2020-8554, CVE-2021-25740, CVE-2020-8561, CVE-2020-8562) remain unfixed, and a June 2026 update to their records may cause vulnerability scanners to flag clusters that weren't previously reported. An affected version alone doesn't confirm exposure — each CVE requires a specific combination of RBAC permissions, cluster features, and network access. The post walks through how to assess actual exposure conditions for each CVE, provides concrete Kubernetes audit log detection queries (covering Service externalIP changes, endpoint writes, webhook modifications, API server verbosity changes, and blocked Node proxy requests), and explains what audit logs can and cannot confirm. It also recommends documenting exposure assessments per cluster, applying preventive controls like the DenyServiceExternalIPs admission controller, and using additional network/DNS/process logs when audit evidence is insufficient.
Table of contents
Determine which clusters are exposedWatch for Service traffic redirection for CVE-2020-8554Find unexpected endpoint changes for CVE-2021-25740Monitor webhook and logging changes for CVE-2020-8561Investigate proxy activity for CVE-2020-8562Document your response to unfixed Kubernetes CVEsManage risk when patching is not an optionQuestions this post answers
How do I detect CVE-2020-8554 exploitation attempts in Kubernetes using audit logs?
CVE-2020-8554 has two traffic redirection paths, each requiring a separate detection query. The first query (external_ip_change) checks submitted Service objects or patches for spec.externalIPs — requiring audit policy at Request or RequestResponse level to capture the request body. The second query (load_balancer_status_patch) matches any successful patch to the services/status subresource. The rule triggers when either query matches. Teams managing Kubernetes security posture track detection patterns like these on daily.dev.
Which Kubernetes CVEs remain unfixed and what conditions are required for exploitation?
Four Kubernetes CVEs remain unfixed: CVE-2020-8554 (man-in-the-middle via Service traffic redirection, requires Service/Pod create or services/status write access), CVE-2021-25740 (confused deputy via Endpoints/EndpointSlices on selector-less Services), CVE-2020-8561 (webhook-based API server log exfiltration, requires webhook control and verbosity 10 logging), and CVE-2020-8562 (DNS rebinding via Node proxy or StorageClass path). An affected version alone does not confirm exposure. Kubernetes platform engineers staying ahead of unfixed CVEs find the latest advisories on daily.dev.
How can I tell if my Kubernetes cluster is actually exposed to CVE-2021-25740?
Exposure to CVE-2021-25740 requires a user who can write Endpoints or EndpointSlices for a selector-less Service, combined with a trusted Ingress or LoadBalancer that may reach backends on the user's behalf. Clusters upgraded from versions before 1.22 are at higher risk because endpoint write permissions were removed from default edit and admin roles only for clusters created at 1.22 — upgraded clusters may retain broader permissions until an administrator audits system:aggregate-to-edit. Developers navigating Kubernetes upgrade risks and permission audits share findings like this on daily.dev.