CVE-2026-32936: CoreDNS DNS-over-HTTPS DoS Vulnerability

CVE-2026-32936 Overview

CVE-2026-32936 is a denial-of-service vulnerability in CoreDNS, the plugin-based DNS server widely deployed in Kubernetes clusters and cloud-native environments. The flaw exists in the DNS-over-HTTPS (DoH) GET request handler in versions prior to 1.14.3. The GET path accepts oversized dns= query parameter values and performs URL parsing, base64 decoding, and DNS message unpacking before any size validation occurs. Unlike the POST path, which enforces a 65536-byte limit through http.MaxBytesReader, the GET path lacks an equivalent bound. A remote, unauthenticated attacker can abuse this asymmetry to exhaust CPU, memory, and garbage-collector resources on the server.

Critical Impact

Unauthenticated remote attackers can degrade or disable CoreDNS resolvers by sending oversized DoH GET requests, disrupting DNS resolution for every dependent workload.

Affected Products

• CoreDNS versions prior to 1.14.3
• Deployments exposing the DNS-over-HTTPS (DoH) GET endpoint
• Kubernetes clusters and cloud-native environments running affected CoreDNS builds

Discovery Timeline

• 2026-05-05 - CVE CVE-2026-32936 published to NVD
• 2026-05-07 - Last updated in NVD database

Technical Details for CVE-2026-32936

Vulnerability Analysis

The vulnerability is a resource exhaustion issue classified under [CWE-400]. CoreDNS implements DoH per RFC 8484, which permits queries via either HTTP POST or HTTP GET. For POST requests, the server wraps the request body in http.MaxBytesReader with a 65536-byte cap, terminating reads that exceed the bound. For GET requests, the encoded DNS message arrives in the dns= URL query parameter, and CoreDNS processes it without first validating the parameter length.

The handler performs URL query parsing, then base64 decoding of the dns= value, then DNS message unpacking. Each stage allocates buffers proportional to the attacker-controlled input. By repeatedly issuing oversized GET requests, an attacker forces sustained CPU consumption, large transient heap allocations, and aggressive Go garbage-collection cycles. The cumulative effect degrades query latency and can render the resolver unresponsive.

Root Cause

The root cause is inconsistent input validation between the DoH POST and GET code paths. The POST path enforces a bounded read before decoding, while the GET path defers all size checks until after expensive parsing operations have already executed. This asymmetry allows attacker-controlled data to drive resource-intensive work prior to rejection.

Attack Vector

Exploitation requires only network access to the DoH endpoint and no authentication or user interaction. An attacker constructs HTTP GET requests with an oversized dns= query parameter value and sends them in volume. Because CoreDNS frequently sits at the core of Kubernetes service discovery, a successful attack disrupts intra-cluster name resolution and any downstream service relying on it. See the GitHub Security Advisory GHSA-63cw-r7xf-jmwr for additional technical context.

Detection Methods for CVE-2026-32936

Indicators of Compromise

• Spikes in CoreDNS process CPU utilization and resident memory not correlated with legitimate query volume.
• HTTP access logs showing a high rate of DoH GET requests with abnormally long dns= query parameter values.
• Increased Go runtime garbage-collection metrics (go_gc_duration_seconds, heap allocations) reported by CoreDNS Prometheus exporters.
• Elevated DNS query latency or timeouts reported by Kubernetes workloads dependent on the resolver.

Detection Strategies

• Inspect HTTP request logs at ingress controllers and load balancers for GET /dns-query requests where the dns= parameter exceeds expected DNS message sizes.
• Alert when CoreDNS pod resource consumption deviates from baseline, correlated with DoH request rate.
• Use web application firewall rules to flag oversized query strings on DoH endpoints.

Monitoring Recommendations

• Export CoreDNS Prometheus metrics and track coredns_dns_request_duration_seconds, process_resident_memory_bytes, and request counts per protocol.
• Forward ingress and CoreDNS logs into a centralized analytics platform for correlation across CPU, memory, and request-size dimensions.
• Configure rate-limiting and request-size thresholds on upstream proxies fronting the DoH endpoint.

How to Mitigate CVE-2026-32936

Immediate Actions Required

• Upgrade CoreDNS to version 1.14.3 or later, which adds bounded reads to the DoH GET path.
• Inventory all CoreDNS deployments, including those embedded in Kubernetes distributions, service meshes, and cloud-managed offerings, and confirm the running version.
• Restrict exposure of the DoH endpoint to trusted networks where operationally feasible.

Patch Information

The issue is fixed in CoreDNS 1.14.3. Release notes and upgrade guidance are available in the CoreDNS Release v1.14.3 announcement. Kubernetes operators should validate compatibility with their cluster version before rolling the update across production nodes.

Workarounds

• Disable the DoH server in the CoreDNS Corefile if DNS-over-HTTPS is not required.
• Place a reverse proxy or WAF in front of CoreDNS that enforces a maximum URL length and query-parameter size on /dns-query requests.
• Apply network-level rate limiting on the DoH endpoint to constrain request volume from any single source.

# Example NGINX rule to bound DoH GET request size before reaching CoreDNS
location /dns-query {
    if ($request_method = GET) {
        set $doh_param_len ${#arg_dns};
        if ($doh_param_len > 8192) { return 414; }
    }
    client_max_body_size 65536;
    proxy_pass https://coredns_upstream;
}