CoreDNS DoH/DoQ/gRPC RFC 2136 UPDATE Bypass

CoreDNS versions 1.14.6 and earlier contain a vulnerability where DNS-over-HTTPS (DoH), DNS-over-HTTPS3 (DoH3), DNS-over-QUIC (DoQ), and DNS-over-gRPC listeners do not enforce the same request policy applied to standard UDP and TCP listeners. Specifically, these modern transports failed to filter out RFC 2136 UPDATE messages. When CoreDNS is configured with the 'forward' or 'proxy' plugin, it forwards these unauthorized UPDATE messages to an upstream authoritative DNS server.

If the upstream server is configured to trust requests originating from the CoreDNS server IP address or an authenticated session, the upstream will process these updates as legitimate requests from the proxy itself. This bypasses the need for the attacker to provide end-to-end TSIG authentication, enabling unauthorized modification, redirection, or deletion of DNS records in the target zone. Defenders should patch CoreDNS to the latest version to ensure UPDATE opcodes are rejected by these transports before plugin dispatch.

Attack Chain

1. Attacker identifies a CoreDNS instance reachable via DoH, DoH3, DoQ, or gRPC.
2. Attacker crafts an RFC 2136 UPDATE packet targeting a zone hosted by an upstream DNS server configured behind the CoreDNS instance.
3. Attacker sends the malicious UPDATE packet to the target CoreDNS instance over one of the vulnerable transports (e.g., DoH).
4. The CoreDNS listener parses the message header without invoking dns.DefaultMsgAcceptFunc to validate the opcode.
5. The CoreDNS server dispatches the unauthorized UPDATE message to the 'forward' or 'proxy' plugin.
6. The 'forward' plugin encapsulates or relays the original UPDATE request to the upstream authoritative server.
7. The upstream server accepts the UPDATE, trusting the request due to the established connection or trusted source IP of the CoreDNS server.
8. The upstream server modifies the DNS record, leading to traffic redirection or zone disruption.

Impact

Successful exploitation allows unauthenticated attackers to manipulate DNS infrastructure. By injecting or altering records, attackers can facilitate traffic redirection (man-in-the-middle), intercept sensitive data, disrupt mail delivery, or take over legitimate names. The scope of impact depends on the sensitivity of the zones managed by the upstream authoritative servers and whether they rely on the CoreDNS proxy for implicit trust.

Recommendation

• Upgrade all instances of CoreDNS to a version containing the fix for CVE-2026-86003.
• Audit CoreDNS 'forward' and 'proxy' plugin configurations to ensure upstream servers require explicit TSIG authentication for all zones that accept dynamic updates.
• Monitor logs for unusual DNS UPDATE activity originating from CoreDNS infrastructure toward sensitive internal or external authoritative zones.
• Restrict access to DoH, DoQ, and gRPC endpoints to authorized clients at the network edge if these services are not required for public exposure.