CVE-2026-82399: Resource Exhaustion Denial of Service in CoreDNS Custom Transports

CoreDNS is a highly configurable, Cloud Native Computing Foundation (CNCF) graduated DNS server written in Go. The architecture of CoreDNS relies on custom plugin chains to process requests and serve records. While standard UDP and TCP listeners leverage the validation routines of the underlying Go DNS library (github.com/miekg/dns), custom secure transport protocols are managed via independent implementations within the CoreDNS codebase.

These custom transport interfaces support modern, encrypted protocols: DNS-over-HTTPS (DoH), DNS-over-QUIC (DoQ), and DNS-over-gRPC. These pathways expose a distinct network-facing attack surface. Because these handlers bypass the initial protocol wrappers of standard DNS listeners, raw network bytes are ingested and handled directly by custom parsing routines.

The vulnerability, designated as CVE-2026-82399, represents a resource allocation flaw classified under CWE-770. Unauthenticated remote attackers can exploit this interface to trigger large, rapid heap allocations. The resulting memory exhaustion bypasses traditional security controls and induces an Out-of-Memory (OOM) termination of the active CoreDNS instance.

The core flaw lies in the sequencing of packet validation within the custom transport listeners. In standard TCP and UDP servers, the incoming wire format is subjected to header validation. The github.com/miekg/dns package implements dns.DefaultMsgAcceptFunc to evaluate the 12-byte fixed DNS header before parsing the payload body. If the header violates standard policy (such as containing multiple question counts), parsing is aborted immediately.

In CoreDNS versions prior to 1.14.7, the custom listeners (plugin/pkg/doh/doh.go, core/dnsserver/server_quic.go, and core/dnsserver/server_grpc.go) did not implement this header-level validation step. Instead, they read the raw payload bytes directly from the network stream and immediately initialized a new dns.Msg structure. The listeners then immediately invoked msg.Unpack(payload) to parse the entire packet.

By calling Unpack() directly, CoreDNS is forced to trust the section count variables defined in the packet's 12-byte header. These counts represent the number of entries in the Question, Answer, Authority, and Additional sections. The parser pre-allocates slice memory proportional to these declared counts. Additionally, when encountering DNS name compression pointers (RFC 1035 Section 4.1.4), the parser recursively resolves the pointers, resulting in a severe memory amplification factor. An attacker can use these nested offsets to force huge string allocations, consuming hundreds of megabytes of memory per request.

Analyzing the patch commit 530b0a5ff2ad68cc0421f10dd93568945cc671c9 reveals how CoreDNS corrected the processing sequence. The primary fix introduces a new package plugin/pkg/dnsutil containing the UnpackRequest helper. This helper reads the 12-byte header explicitly, validates it via the official library policy, and rejects invalid structures before calling the resource-intensive Unpack method.

// plugin/pkg/dnsutil/message.go
package dnsutil
 
import (
	"encoding/binary"
	"errors"
	"github.com/miekg/dns"
)
 
var errRequestRejected = errors.New("dns request rejected")
 
// UnpackRequest unpacks a request after applying the default miekg/dns request policy.
func UnpackRequest(msg []byte) (*dns.Msg, error) {
	var header dns.Header
	// Safely decode only the first 12 bytes of the message to parse the header
	if _, err := binary.Decode(msg, binary.BigEndian, &header); err != nil {
		return nil, dns.ErrBuf
	}
	// Check if the header conforms to the standard DNS message policy
	if dns.DefaultMsgAcceptFunc(header) != dns.MsgAccept {
		return nil, errRequestRejected
	}
 
	request := new(dns.Msg)
	// Proceed to unpack the entire payload only after the header is validated
	return request, request.Unpack(msg)
}

The custom handlers were updated to integrate this check. For example, in core/dnsserver/server_quic.go, the unsafe invocation is replaced by the secure wrapper:

// Vulnerable implementation
req := &dns.Msg{}
err = req.Unpack(buf)
 
// Patched implementation
req, err := dnsutil.UnpackRequest(buf)

This structural modification ensures that any malformed message containing an excessive question count or nested pointers is rejected during the 12-byte header check. No significant heap allocation or recursive pointer decompression occurs for malformed requests.

To visualize the packet handling logic and the vulnerability's placement in the pipeline, refer to the sequence diagram below. This diagram illustrates how the omission of the header check allowed payloads to bypass initial filtering.

The sequence demonstrates that because heap allocation is triggered in the unpacking layer, subsequent processing blocks (such as security plugins) are never reached. Mitigations must occur at or before this deserialization phase to protect server resources.

Exploitation of CVE-2026-82399 relies on crafting a DNS packet containing highly compressed domain structures paired with an inflated question count. Because the transport endpoints do not validate the 12-byte header prior to unpacking, the parser is forced to process the entire query immediately. The attacker targets DoH (/dns-query), DoQ, or gRPC listeners.

An attack packet is structured with the QDCOUNT (Question Count) field configured to a high value, such as 0x2A7E (10,878 questions). The first question contains a standard domain string (e.g., \x07example\x03com\x00). Subsequent questions do not define new strings; instead, they consist of compression pointers referencing the first question's byte offset (0xC00C).

+-------------------------------------------------------------+
| DNS Header (12 bytes)                                       |
| ID: 0x1234 | Flags: 0x0100 | QDCOUNT: 0x2A7E (10,878 Qs)   |
+-------------------------------------------------------------+
| First Question:                                             |
| \x07example\x03com\x00 | Type: A (0x0001) | Class: IN (0x0001)     |
+-------------------------------------------------------------+
| Questions 2 - 10,878:                                       |
| Offset Pointer: 0xC00C | Type: A | Class: IN                 |
+-------------------------------------------------------------+

When the vulnerable CoreDNS server processes this payload, the parser attempts to reconstruct the domain name for each of the 10,878 references. This forces the Go runtime to pre-allocate massive internal slices on the heap and iteratively construct string representations. This decompression cycle achieves an allocation amplification factor exceeding 150x. Under concurrent load, several threads processing such payloads will trigger the Linux Out-Of-Memory (OOM) killer, terminating the DNS service.

The ultimate impact of successful exploitation is a complete Denial of Service (DoS) of the CoreDNS server. Because DNS is a foundation block of modern cloud infrastructure (especially inside Kubernetes clusters), the termination of CoreDNS has cascading effects. Microservices lose the ability to resolve external APIs, database endpoints, or internal cluster services, resulting in widespread service failure.

The vulnerability is rated 7.5 (High) under CVSS v3.1. The attack vector is Network, and the complexity is Low, requiring no special privileges or user interaction. Although it does not permit remote code execution (RCE) or data exfiltration, the impact on Availability is absolute.

Furthermore, because the crash occurs during packet parsing before the CoreDNS plugin architecture is initialized, traditional rate-limiting plugins (such as ratelimit) or access controls (such as acl) are bypassed. The server's memory is exhausted before any plugin can inspect or drop the malicious connection, making network-level filtering or application updates the only viable avenues of protection.

The primary and recommended mitigation is upgrading CoreDNS to version 1.14.7 or higher. This version integrates the dnsutil.UnpackRequest wrapper across all custom secure listeners, ensuring malformed packet headers are rejected before allocation or decompression can take place.

If immediate upgrading is not feasible, several tactical workarounds can be deployed. For environments running DNS-over-HTTPS (DoH), a Web Application Firewall (WAF) or reverse proxy can be positioned in front of the CoreDNS instances. The WAF should be configured to inspect HTTP POST requests to /dns-query and block payloads where the DNS header bytes (specifically bytes 4-5 representing QDCOUNT) exceed a safe threshold (typically QDCOUNT <= 1).

Additionally, if DoH, DoQ, or DNS-over-gRPC are not required for network operations, these listeners should be disabled in the Corefile. Restricting DNS services solely to standard UDP and TCP listeners removes the vulnerable code paths from the active attack surface. Standard listeners natively utilize the underlying library's secure parsing routine and are not affected by this vulnerability.