CVE-2026-86003: CoreDNS DoH/DoQ/gRPC bypass UPDATE rejection enforced on UDP/TCP
CoreDNS is a DNS server written in Go. Prior to 1.14.7, the DNS-over-HTTPS, DNS-over-HTTP/3, DNS-over-QUIC, and DNS-over-gRPC listeners in plugin/pkg/doh/doh.go, core/dnsserver/serverquic.go, and core/dnsserver/servergrpc.go call dns.Msg.Unpack without the dns.DefaultMsgAcceptFunc request policy used by UDP, TCP, and DNS-over-TLS. An unauthenticated client can send an RFC 2136 UPDATE that the proxy or forward plugin passes unchanged to an update-capable upstream. If that upstream trusts CoreDNS's source address or connection and does not require an attacker-unknown end-to-end TSIG, the request appears to originate from CoreDNS and can add, replace, or delete DNS records, redirect traffic, take over names, alter mail routing, or disrupt the writable zone. This issue is fixed in version 1.14.7.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade to a fixed release to a version that resolves this vulnerability.
Fixed in 1.14.7
Event History
Frequently Asked Questions
Which deployments are exposed to this issue?
CoreDNS versions prior to 1.14.7 are exposed when they accept DNS-over-HTTPS, DNS-over-HTTP/3, DNS-over-QUIC, or DNS-over-gRPC requests and proxy or forward them to an upstream that can process DNS UPDATE requests. Exploitation also depends on the upstream trusting CoreDNS's source address or connection and not requiring an end-to-end TSIG unknown to the attacker.
What does an attacker need to exploit it?
An unauthenticated client only needs network access to an affected encrypted or gRPC CoreDNS listener. They must be able to submit an RFC 2136 UPDATE that CoreDNS passes unchanged to a writable upstream meeting the stated trust conditions.
Are standard UDP, TCP, or DNS-over-TLS listeners affected?
No. UDP, TCP, and DNS-over-TLS use the dns.DefaultMsgAcceptFunc request policy that rejects these UPDATE requests; the bypass is limited to the listed DoH, HTTP/3, QUIC, and gRPC listeners.
What is the immediate mitigation if upgrading is not possible?
Prevent untrusted clients from reaching the affected DoH, HTTP/3, QUIC, and gRPC listeners, or ensure those listeners cannot forward or proxy UPDATE requests to writable upstreams. Requiring an attacker-unknown end-to-end TSIG at the upstream also prevents the described trust bypass.
How can I determine whether an upstream is at risk?
Identify whether CoreDNS forwards or proxies requests from the affected listener types to an update-capable DNS upstream. The upstream is at risk if it accepts UPDATEs based on CoreDNS's source address or connection rather than requiring end-to-end TSIG authentication.