CoreDNS before version 1.14.7 accepted RFC 2136 UPDATE messages over DNS-over-HTTPS (DoH), DoH3, DNS-over-QUIC (DoQ), and DNS-over-gRPC transports without rejecting the UPDATE opcode as done on UDP and TCP. This occurred because these listeners called dns.Msg.Unpack without applying the request policy that rejects UPDATE opcodes before plugin dispatch. Consequently, the proxy/forward plugin forwarded these UPDATE messages unchanged to upstream DNS servers. If an upstream server trusts CoreDNS's source address or authenticated connection rather than requiring end-to-end TSIG authentication, an unauthenticated client can add, replace, or delete DNS records via CoreDNS. The fix applies the standard request acceptance policy to raw headers before dispatching requests on these transports.

An unauthenticated attacker can send DNS UPDATE requests over DoH, DoH3, DoQ, or DNS-over-gRPC to a vulnerable CoreDNS server and cause it to forward these requests to an upstream DNS server. If the upstream server trusts CoreDNS's connection or source address without requiring end-to-end TSIG authentication, this can lead to unauthorized modification of DNS records (additions, replacements, deletions). This could compromise DNS integrity and potentially disrupt services relying on DNS.

A patch is available and should be applied to CoreDNS to enforce the correct request acceptance policy on all affected transports (DoH, DoH3, DoQ, DNS-over-gRPC) before dispatching requests. This fix prevents UPDATE opcode messages from being forwarded unless properly authenticated. Users should upgrade to CoreDNS version 1.14.7 or later. No additional mitigation is required if the patch is applied.