CoreDNS CVE-2026-62994

Three conditions must simultaneously hold: (1) CoreDNS must be configured with the k8s_external plugin specifically handling headless-service zone transfers - this is a non-default, operator-configured deployment mode; (2) the Kubernetes cluster must contain at least one headless service endpoint with no declared ports, which causes plugin/kubernetes/object/endpoint.go to generate Port: -1 internally; and (3) the attacker must have AXFR access permitted by the CoreDNS transfer plugin ACL from their network location - AXFR is not open by default and typically restricted to trusted secondaries. Exploitation is limited by: the AXFR ACL requirement (eliminates unauthenticated internet-facing exploitation in default configurations), the k8s_external plugin not being universally deployed, and the requirement for a specific Kubernetes resource state. Standard A, AAAA, and SRV queries do not traverse this code path.

The official CVSS 3.1 score of 3.7 (Low) with vector AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:L accurately reflects a remotely triggerable but conditionally gated denial of service. AC:H captures the multi-condition prerequisite: k8s_external must be deployed, a portless headless service must exist in Kubernetes, and AXFR must be permitted from the attacker's source. EPSS data is absent from the input and cannot be assessed. CoreDNS is not listed in CISA KEV and no public exploit code has been identified, though the fix commit and advisory are publicly accessible. Despite the low base score, operational impact in a Kubernetes cluster is disproportionate - a CoreDNS panic disrupts all pod-to-pod DNS resolution until the process is restarted. Environments running k8s_external with any portless headless service should treat this as an elevated operational risk relative to the CVSS score alone. Environments not using the k8s_external plugin are not affected regardless of CoreDNS version.

A network client permitted to send AXFR requests to a CoreDNS instance sends a zone transfer request for a zone managed by the k8s_external plugin. If the Kubernetes cluster contains any headless service with no declared ports - even an unused or test service - the transfer plugin encounters an empty DNS record batch and panics on the unchecked records[0] access, immediately crashing the CoreDNS process. In a Kubernetes cluster, this causes all pod DNS resolution to fail until Kubernetes restarts the CoreDNS pod.