CVE-2026-86003 in CoreDNS
Summary
by MITRE • 09/16/2026
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/server_quic.go, and core/dnsserver/server_grpc.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.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 09/16/2026
CoreDNS serves as a critical infrastructure component for modern network environments, functioning as a flexible and extensible Domain Name System server written in Go. The vulnerability identified affects versions prior to 1.14.7 and specifically targets the protocol listeners designed for encrypted DNS transports, including DNS-over-HTTPS, DNS-over-HTTP/3, DNS-over-QUIC, and DNS-over-gRPC. These components are implemented within specific source files such as plugin/pkg/doh/doh.go, core/dnsserver/server_quic.go, and core/dnsserver/server_grpc.go. The fundamental technical flaw lies in the handling of incoming requests by these listeners, which invoke dns.Msg.Unpack without applying the strict request policy defined by dns.DefaultMsgAcceptFunc. This default function is standardly utilized for legacy UDP, TCP, and DNS-over-TLS connections to enforce security constraints on message structure and content. By omitting this validation step for newer encrypted protocols, CoreDNS inadvertently accepts a broader range of malformed or malicious messages than intended, creating an inconsistency in the server's defense-in-depth posture across different transport layers.
The operational impact of this vulnerability is severe due to its interaction with dynamic DNS update mechanisms defined by RFC 2136. An unauthenticated attacker can exploit this flaw by crafting and sending a specially constructed UPDATE request through any of the affected encrypted channels. When CoreDNS operates in proxy or forwarder mode, it may pass these requests unchanged to an upstream authoritative server that supports dynamic updates. If the upstream server is configured to trust connections based on their source IP address or existing TLS/QUIC connection context rather than requiring end-to-end Transaction Signature authentication with a shared secret unknown to the attacker, the malicious request will be accepted as legitimate. This bypass of authentication allows the attacker to perform unauthorized modifications to the DNS zone data hosted by the upstream server.
The consequences of such unauthorized access are extensive and can lead to significant disruptions in network operations and security posture. An attacker capable of injecting or modifying records can redirect traffic for critical services, effectively performing man-in-the-middle attacks at the resolution layer. They may take over domain names, alter mail exchange records to intercept sensitive communications, or delete essential resource records to cause denial-of-service conditions. This vulnerability is categorized under CWE-284 Improper Access Control and aligns with MITRE ATT&CK techniques related to DNS Tunneling and Domain Generation Algorithm evasion if used for malicious redirection. The lack of consistent validation across transport protocols represents a significant oversight in the application's security design, allowing attackers to leverage less commonly monitored encrypted channels to bypass traditional perimeter defenses that rely on UDP/TCP filtering rules.
To mitigate this risk, organizations running CoreDNS must immediately upgrade to version 1.14.7 or later, where the dns.DefaultMsgAcceptFunc is correctly applied to all listener types, ensuring uniform security policies regardless of the transport protocol used. In environments where upgrading is not immediately feasible, administrators should consider restricting access to DNS-over-HTTPS and other encrypted endpoints using network-level firewall rules that limit source IPs to trusted clients only. Additionally, configuring upstream servers to require TSIG authentication for dynamic updates provides a robust defense-in-depth measure, ensuring that even if CoreDNS passes through malicious requests, the authoritative server will reject them due to missing or invalid cryptographic signatures. Regular auditing of DNS configuration and monitoring for anomalous update activity can further aid in detecting potential exploitation attempts before significant damage occurs.