CVE-2026-86003

CoreDNS's DNS-over-HTTPS, DNS-over-HTTP/3, DNS-over-QUIC, and DNS-over-gRPC listeners (in plugin/pkg/doh/doh.go, core/dnsserver/server_quic.go, and core/dnsserver/server_grpc.go) unpack requests without applying dns.DefaultMsgAcceptFunc, the screening policy that the UDP, TCP, and DNS-over-TLS listeners enforce. As a result, an unauthenticated remote client can submit an RFC 2136 dynamic UPDATE over DoH/DoH3/DoQ/DoG, which the proxy or forward plugin relays 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 attacker can add, replace, or delete DNS records to redirect traffic, take over names, alter mail routing, or corrupt a writable zone. Any CoreDNS deployment prior to 1.14.7 that exposes these listeners and forwards to dynamic-update-capable upstreams is affected, a notable population since CoreDNS is the default DNS server in Kubernetes. No exploitation has been reported (not in CISA KEV, no public PoC), and a fix ships in CoreDNS 1.14.7.

What to do: Upgrade to CoreDNS 1.14.7. Until then, do not expose DoH/DoH3/DoQ/DoG listeners to untrusted networks, and require end-to-end TSIG on any upstream zone accepting RFC 2136 updates instead of trusting CoreDNS's source address. Audit Corefiles for doh://, quic:// (h3), and grpc:// server blocks and verify whether their forward/proxy upstreams accept dynamic DNS UPDATEs.