CVE-2026-62299 in CoreDNS
Summary
by MITRE • 07/16/2026
CoreDNS is a DNS server written in Go. Prior to 1.14.5, the CoreDNS rewrite plugin supports edns0 rewrite rules with an optional revert flag, and two response rules, edns0SetResponseRule and edns0ReplaceResponseRule[T] in plugin/rewrite/edns0.go, call res.IsEdns0() and immediately dereference the returned *dns.OPT without a nil check when a downstream plugin returns a response with no OPT record. A remote, unauthenticated client can send a single ordinary DNS query matching a rewrite edns0 <local|nsid|subnet> <set|append|replace> ... revert rule, causing ResponseReverter in plugin/rewrite/reverter.go to panic, return SERVFAIL, and degrade availability, or crash the CoreDNS process if the debug directive disables recovery. This issue is fixed in version 1.14.5.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 07/16/2026
The vulnerability exists within CoreDNS version 1.14.4 and earlier, specifically affecting the rewrite plugin's handling of EDNS0 rewrite rules. The core issue stems from insufficient null pointer validation when processing DNS responses that lack OPT records. When a downstream plugin returns a response without an OPT record, the edns0SetResponseRule and edns0ReplaceResponseRule functions in plugin/rewrite/edns0.go directly dereference the result of res.IsEdns0() without first verifying whether the returned *dns.OPT pointer is nil. This fundamental programming error creates a path for denial of service attacks through carefully crafted DNS queries that match specific rewrite rules with revert flags.
The operational impact of this vulnerability manifests as a remote, unauthenticated client can trigger a panic condition by sending a single ordinary DNS query that matches an edns0 rewrite rule with a revert flag. When the ResponseReverter component in plugin/rewrite/reverter.go encounters this scenario, it either returns a SERVFAIL response to degrade service availability or causes the entire CoreDNS process to crash if the debug directive is enabled and recovery mechanisms are disabled. This represents a critical availability risk that can be exploited by any remote attacker without authentication requirements, making it particularly dangerous in production environments where DNS servers serve as foundational infrastructure components.
This vulnerability aligns with CWE-476, which addresses null pointer dereference conditions in software implementations, and demonstrates poor error handling practices in network protocol processing. The issue also maps to ATT&CK technique T1499.004, which covers network denial of service attacks through exploitation of application vulnerabilities. The exploitability is enhanced by the fact that attackers need only send a single query to trigger the condition, requiring no complex multi-step attack vectors. The fix implemented in CoreDNS version 1.14.5 addresses this by adding proper nil checks before dereferencing OPT record pointers, ensuring robust handling of responses that may lack EDNS0 information while maintaining the intended functionality of the rewrite plugin's EDNS0 capabilities.
The broader implications extend beyond simple availability concerns, as this vulnerability could be leveraged in coordinated attacks against DNS infrastructure, potentially causing cascading failures in systems that depend on stable DNS resolution. Organizations running affected CoreDNS versions should prioritize immediate patching to prevent exploitation, particularly those operating critical infrastructure where DNS service degradation could have significant business impact. The vulnerability serves as a reminder of the importance of defensive programming practices when handling network protocol responses, especially in widely deployed software components that process untrusted input from remote clients.