CVE-2026-32936

What it actually does

CoreDNS versions before 1.14.3 can perform expensive processing on oversized DNS-over-HTTPS GET requests before enforcing a practical size limit. The vulnerable path accepts a large `dns=` URL query parameter, parses the URL query, base64-decodes the value, and attempts to unpack it as a DNS message before rejecting it. Because this work is unauthenticated and attacker-controlled, repeated requests can drive excessive CPU consumption, transient memory allocation, and Go garbage-collection pressure, reducing or eliminating DNS service availability. The POST DoH path is not affected in the same way because it uses a bounded read limit.

Why it matters to the business

Successful exploitation can make CoreDNS slow or unavailable, disrupting name resolution for applications, services, clusters, and users that depend on it. In environments where CoreDNS is part of Kubernetes, service discovery, internal DNS, or public recursive/authoritative DNS, this can cause broad application outages even though the flaw does not directly expose data or allow code execution. The issue is remotely exploitable without authentication, but current public exploitation signals are low: EPSS is approximately 0.0067, unchanged over 30 days, it is not listed in CISA KEV, and no mature exploit is currently reported.

How an attack unfolds

An attacker identifies a CoreDNS deployment exposing the DNS-over-HTTPS endpoint, commonly `/dns-query`, and sends repeated HTTP GET requests containing an abnormally large `dns=` query parameter. The server accepts the request far enough to parse the URL, decode the parameter, and attempt DNS message unpacking. Even if the request is ultimately invalid, the vulnerable code has already consumed CPU and allocated memory. By sending many such requests concurrently or at sustained volume, the attacker can create garbage-collection pressure and resource exhaustion, causing elevated latency, dropped queries, failed health checks, pod or process restarts, or total DNS denial of service.

How to fix it

Upgrade CoreDNS to version 1.14.3 or later. Where immediate upgrade is not possible, reduce exposure of DNS-over-HTTPS GET endpoints by restricting access to trusted networks, placing DoH behind a proxy or gateway that enforces strict URL and query-string length limits, rate-limiting `/dns-query` requests, and blocking or rejecting unusually large `dns=` query parameters before they reach CoreDNS. If DoH GET is not required, disable or block GET access to the DoH endpoint while preserving required DNS service paths. Ensure mitigations are applied at every exposed CoreDNS instance, including container images, Helm charts, Kubernetes add-ons, appliances, and downstream distributions that bundle CoreDNS.

How to confirm the fix worked

Confirm all running CoreDNS binaries and container images report version 1.14.3 or later. Review deployment manifests, package inventories, image tags, and runtime process versions rather than relying only on source repositories. Test externally and internally exposed DoH endpoints to verify oversized GET requests are rejected quickly by a patched CoreDNS instance or by an upstream proxy before heavy backend processing occurs. Monitor resource behavior during controlled negative testing: patched or properly mitigated systems should not show sustained CPU spikes, large memory growth, or increased garbage-collection pressure from oversized `dns=` requests. Validate that access controls, WAF/proxy rules, and rate limits apply specifically to `/dns-query` GET requests and long query strings.

Typical attack path

1. Locate an exposed CoreDNS DNS-over-HTTPS endpoint, such as `/dns-query`.
2. Send HTTP GET requests with an oversized `dns=` query parameter.
3. Force CoreDNS to perform URL query parsing, base64 decoding, and DNS message unpacking on attacker-controlled oversized input.
4. Repeat requests at sufficient rate or concurrency to increase CPU usage, memory allocation, and garbage collection.
5. Degrade or exhaust CoreDNS capacity, causing DNS resolution failures or service unavailability.

How to detect it

Investigate HTTP access logs from reverse proxies, ingress controllers, load balancers, API gateways, WAFs, and any CoreDNS DoH logging for repeated GET requests to `/dns-query` containing unusually long `dns=` query parameters. Focus on high request rates from single sources, distributed bursts, long URL/query-string lengths, abnormal 400/414/431/500/502/503 responses, and requests that correlate with CoreDNS CPU spikes, memory growth, garbage-collection pressure, DNS latency, SERVFAIL increases, pod restarts, process restarts, or health-check failures. Review Kubernetes events, container runtime logs, systemd journals, process supervisors, and metrics platforms for OOM kills, restart loops, throttling, or sustained resource exhaustion around the same timestamps. Because exploitation is a denial-of-service pattern rather than code execution, there may be no persistent file, process, or registry artifact; the strongest evidence is temporal correlation between oversized DoH GET traffic and CoreDNS resource degradation.

• GET /dns-query?dns=
• /dns-query?dns=
• request_uri="/dns-query?dns=
• request_method="GET" uri="/dns-query?dns=
• http.request.method: GET AND url.path: /dns-query AND url.query: dns=
• 414 Request-URI Too Large
• 414 URI Too Long
• 431 Request Header Fields Too Large
• upstream timed out
• context deadline exceeded
• OOMKilled
• Back-off restarting failed container
• plugin/doh
• coredns

What your security team should do

• Inventory all CoreDNS deployments, including Kubernetes-managed instances, container images, embedded distributions, and externally exposed DNS-over-HTTPS services.
• Upgrade CoreDNS to 1.14.3 or later as the primary remediation.
• Prioritize internet-facing or broadly reachable DoH endpoints, followed by internal shared DNS infrastructure supporting critical applications or clusters.
• Add proxy, ingress, load balancer, or WAF controls to reject oversized URLs and oversized `dns=` query parameters on `/dns-query`.
• Rate-limit DNS-over-HTTPS GET requests and alert on spikes in long-query requests, HTTP 4xx responses, CPU saturation, memory pressure, garbage-collection pressure, restarts, or DNS latency.
• If DoH GET is unnecessary, disable or block it and allow only required DNS transports and methods.
• Review logs and metrics from the period since publication for evidence of repeated oversized DoH GET requests or unexplained CoreDNS resource exhaustion.
• Document the patched version in vulnerability management records and verify downstream packages or platform add-ons have incorporated CoreDNS 1.14.3 or later.