CVE-2026-86003: Unintended Proxying of DNS UPDATE Requests via Alternative Transports in CoreDNS

CoreDNS is a modular DNS server widely deployed in cloud-native environments, including as the default name resolution service in Kubernetes clusters.\n\nThe vulnerability tracked as CVE-2026-86003 is an architectural validation bypass affecting alternative transport implementations within CoreDNS. These alternative transport endpoints include DNS-over-HTTPS (DoH), DNS-over-HTTP/3 (DoH3), DNS-over-QUIC (DoQ), and DNS-over-gRPC.\n\nWhile traditional UDP, TCP, and DNS-over-TLS (DoT) servers enforce strict message validation policies on incoming packets, the alternative transport listeners failed to invoke the default validation framework when parsing network frames. This allows unauthenticated remote attackers to send unauthorized dynamic DNS update queries that the server subsequently processes and forwards to upstream authoritative resolvers.

In CoreDNS, incoming DNS messages processed over standard UDP or TCP transports are routed through parsing wrappers that leverage the default message acceptance logic defined by the Go DNS library ('github.com/miekg/dns'). The central function 'dns.DefaultMsgAcceptFunc' validates header opcodes and flags, rejecting administrative opcodes like 'UPDATE' (Opcode 5) by default.\n\nIn affected CoreDNS versions prior to 1.14.7, alternative and encrypted transports handled payload extraction independently. Rather than passing the raw extracted byte payloads through the validated deserialization logic, these handlers directly invoked the library's raw 'Unpack()' method on the unpacked message instances.\n\nThe 'Unpack()' method deserializes wire bytes into a 'dns.Msg' structure but does not enforce the 'dns.DefaultMsgAcceptFunc' filtering. This allows any unauthenticated client to deliver high-privilege opcodes, such as RFC 2136 'UPDATE' payloads, without triggering the boundary access controls. The unpacked message is subsequently treated as a normal DNS query and routed into the core plugin architecture.

To visualize the propagation of unauthorized payloads, consider the network path of the exploit from the attacker to the internal DNS infrastructure.\n\nmermaid\ngraph LR\n Attacker[\"Untrusted Attacker\"]\n CoreDNS[\"CoreDNS Server (Vulnerable Listener)\"]\n Upstream[\"Upstream Authoritative DNS Server\"]\n\n Attacker -- \"DoH POST /dns-query<br>(Opcode 5: UPDATE)\" --> CoreDNS\n CoreDNS -- \"Raw DNS Update (Opcode 5)<br>(CoreDNS Source IP)\" --> Upstream\n Upstream -- \"Processes Update\" --> Upstream\n\n\nWhen CoreDNS forwards the unpacked message via the 'forward' or 'proxy' plugins, the packet arrives at the upstream authoritative nameserver with the source IP of the CoreDNS pod or server. Because many environments establish trusted zones based on internal IP allowlists, the upstream server assumes the request is legitimate and executes the record update.

The vulnerability was addressed in commit '530b0a5ff2ad68cc0421f10dd93568945cc671c9' by introducing a standardized request parsing helper under 'plugin/pkg/dnsutil/message.go'.\n\nThis utility, 'UnpackRequest', explicitly decodes the DNS header structure and runs validation prior to performing full deserialization. This prevents raw 'UPDATE' operations from propagating further.\n\ngo\npackage dnsutil\n\nimport (\n\t\"encoding/binary\"\n\t\"errors\"\n\n\t\"github.com/miekg/dns\"\n)\n\nvar errRequestRejected = errors.New(\"dns request rejected\")\n\n// UnpackRequest unpacks a request after applying the default miekg/dns request policy.\nfunc UnpackRequest(msg []byte) (*dns.Msg, error) {\n\tvar header dns.Header\n\t// Partially decode the wire packet header\n\tif _, err := binary.Decode(msg, binary.BigEndian, &header); err != nil {\n\t\treturn nil, dns.ErrBuf\n\t}\n\t// Validate the header flags using the standard acceptance function\n\tif dns.DefaultMsgAcceptFunc(header) != dns.MsgAccept {\n\t\treturn nil, errRequestRejected\n\t}\n\n\trequest := new(dns.Msg)\n\treturn request, request.Unpack(msg)\n}\n\n\nThe alternative listeners, such as the gRPC listener ('core/dnsserver/server_grpc.go'), were then modified to utilize 'dnsutil.UnpackRequest' instead of direct unpacking:\n\ndiff\n-msg := new(dns.Msg)\n-err := msg.Unpack(in.GetMsg())\n+msg, err := dnsutil.UnpackRequest(in.GetMsg())\n if err != nil {\n \treturn nil, err\n }\n

An attacker targeting this vulnerability must identify a CoreDNS instance exposing an alternative transport mechanism, such as a DNS-over-HTTPS (DoH) endpoint. The attacker does not require credentials or access to the internal network if the DoH server is exposed externally.\n\nThe attacker crafts a binary-encoded RFC 2136 DNS UPDATE query. This message specifies the targeted domain zone (e.g., 'internal.zone') and includes Resource Record modification directives (e.g., adding an 'A' record pointing to a rogue IP address).\n\nThe payload is then encapsulated inside an HTTP POST request to the '/dns-query' path, utilizing the 'application/dns-message' content type. Because the DoH handler does not validate the header opcode, the CoreDNS server treats it as a legitimate request, matches the zone against the 'forward' plugin, and forwards it to the upstream nameserver under its own trusted IP footprint.

The impact of a successful exploitation is a complete compromise of integrity for DNS records handled by the trusted upstream server. Attackers can hijack internal domain resolution, route traffic to malicious servers, manipulate MX records to intercept corporate mail, or delete existing host entries to disrupt services.\n\nOrganizations should immediately upgrade CoreDNS deployments to version 1.14.7 or later. This release enforces validation across all transport pathways.\n\nFor systems where immediate upgrades are unfeasible, defensive actions include disabling the 'doh', 'grpc', or 'quic' plugins in the active 'Corefile' configuration. Furthermore, upstream servers must be reconfigured to require cryptographic Transaction Signatures (TSIG) for any zone modification commands, neutralizing source-IP based authorization mechanisms.