CoreDNS EUVD-2026-45020

Exploitation requires that the CoreDNS rewrite plugin is configured with at least one edns0 rewrite rule that includes the optional revert flag - specifically using the form 'rewrite edns0 <local|nsid|subnet> <set|append|replace> ... revert'. This is a non-default configuration; CoreDNS installations that do not use the rewrite plugin or that use edns0 rules without the revert flag are not affected. The attacker's query must match the configured rule pattern, but no special crafting beyond a standard DNS query is required - the vulnerable code path is triggered by the absence of an OPT record in the downstream response, not by anything in the attacker's query itself. No authentication is required per CVSS PR:N. The crash outcome (versus SERVFAIL degradation) is additionally limited to deployments where the CoreDNS debug directive has been explicitly added to the Corefile, disabling default panic recovery.

The CVSS 3.1 base score of 5.3 (Medium) with vector AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L accurately reflects the default-deployment outcome: a SERVFAIL response rather than a process crash. However, the real-world severity is deployment-dependent. In environments running CoreDNS with the debug directive active, the panic is not recovered and the process terminates, elevating the effective availability impact from partial to complete - the CVSS base score understates this scenario. In Kubernetes clusters, CoreDNS is the exclusive in-cluster DNS resolver; crashing it via repeated queries would deny all DNS resolution to all workloads, making this a high-impact denial-of-service in that context. The attack requires no authentication (PR:N) and no interaction (UI:N) and can be triggered with a single valid DNS query of minimal complexity (AC:L once the matching rule is deployed). No KEV listing and no public exploit have been identified at time of analysis; EPSS data was not provided. The risk is therefore credible but currently theoretical - real-world priority should be elevated for any Kubernetes deployment where the rewrite plugin is configured with edns0 revert rules.

An attacker with network access to a CoreDNS instance that has an edns0 rewrite revert rule configured sends a single standard DNS A query (no OPT record required) for a domain matching the rule's pattern. CoreDNS rewrites the request, forwards it to a downstream handler, and the handler returns a response without an OPT record; during response post-processing, the ResponseReverter dereferences a nil pointer and panics. In a Kubernetes cluster with debug mode enabled, CoreDNS terminates, the pod enters a crash loop, and all workloads in the cluster lose DNS resolution until the pod recovers.