Executive brief
CoreDNS, a DNS server commonly used in cloud and containerized environments, failed to block unauthorized DNS record modification requests (RFC 2136 UPDATE messages) when received over encrypted protocols like HTTPS (DoH), QUIC (DoQ), and gRPC. An attacker could exploit this to modify DNS records through CoreDNS if the upstream server trusts CoreDNS's connection without requiring cryptographic authentication, potentially redirecting traffic or compromising domain ownership.
Technical details
CoreDNS's DoH, DoH3, DoQ, and DNS-over-gRPC listeners accepted RFC 2136 UPDATE messages (opcode 5) without enforcing the request policy applied by UDP/TCP listeners, which reject non-QUERY/NOTIFY opcodes. The vulnerable code parsed incoming messages via dns.Msg.Unpack without the restrictive DefaultMsgAcceptFunc. Requests were routed based on the Zone question and forwarded unchanged to the upstream, appearing to originate from CoreDNS. An unauthenticated attacker with network access to these listeners could send UPDATE messages that an update-capable upstream would accept if it trusts CoreDNS's source address or authenticated connection instead of requiring end-to-end TSIG validation. The fix applies dnsutil.UnpackRequest, which enforces the same opcode restrictions on all affected transports.
Affected products
- CoreDNS CoreDNS before 530b0a5ff2ad68cc0421f10dd93568945cc671c9 (main branch)
Timeline
- 2026-09-17: disclosed
- 2026-09-17: advisory