CVE-2026-32934

What it actually does

CoreDNS versions before 1.14.3 have a remotely triggerable denial-of-service flaw in the DNS-over-QUIC server. An unauthenticated client can open many QUIC streams and send only one byte on each stream. CoreDNS accepts the streams and creates goroutines waiting for worker-pool tokens even when the pool is exhausted, while active workers block indefinitely in io.ReadFull() waiting for the second byte of the DoQ length prefix because no per-stream read deadline is enforced. The result is unbounded goroutine and memory growth that can exhaust memory and cause the CoreDNS process or container to be OOM-killed.

Why it matters to the business

Successful exploitation can make DNS resolution unavailable for applications, clusters, services, or networks that depend on vulnerable CoreDNS instances. Because DNS is often a foundational dependency, the operational impact can cascade into application outages, failed service discovery, degraded Kubernetes workloads, failed deployments, and broad connectivity issues. The issue is network-accessible, unauthenticated, and low-complexity, but current EPSS is low, there is no known KEV listing, no known ransomware association, and no public exploit maturity reported in the supplied data, so remediation should be prioritized based on whether DNS-over-QUIC is exposed to untrusted networks.

How an attack unfolds

An attacker first identifies a CoreDNS deployment exposing DNS-over-QUIC, commonly over UDP on the DoQ service port. The attacker establishes QUIC connectivity and repeatedly opens a large number of streams. Instead of sending a complete DoQ message length prefix and DNS payload, the attacker sends only a single byte per stream and leaves the streams open. CoreDNS assigns workers that then block in a read operation waiting for the missing byte, while additional accepted streams cause more goroutines to be created waiting for worker availability. Repeating this pattern consumes memory and scheduler resources until the CoreDNS process becomes unstable, is killed by the operating system or container runtime, or stops responding to legitimate DNS requests.

How to fix it

Upgrade CoreDNS to version 1.14.3 or later. The vendor states this issue is fixed in 1.14.3 and no known workarounds exist. Where immediate upgrade is not possible, reduce exposure as a risk-control measure: disable DNS-over-QUIC if it is not required, restrict DoQ access to trusted clients or internal networks, block or rate-limit untrusted UDP traffic to the DoQ listener, enforce network-level connection and stream abuse controls where available, and ensure CoreDNS has resource limits and health-based restart policies so failures are contained. These mitigations reduce attackability but should not be treated as a complete fix.

How to confirm the fix worked

Confirm the running CoreDNS version is 1.14.3 or later using the deployed binary, package, image tag, or release manifest. Review CoreDNS configuration for DNS-over-QUIC listeners, such as quic:// server blocks or UDP/853 exposure, and confirm any unnecessary DoQ listener is disabled or restricted. Validate externally that untrusted networks cannot reach the DoQ endpoint. In containerized environments, verify all CoreDNS pods or replicas are running the fixed image and that no older replicas remain. After patching, perform controlled DoQ connectivity and load testing to ensure CoreDNS continues to answer legitimate DNS queries without abnormal goroutine, memory, restart, or OOM-kill behavior.

Typical attack path

1. Discover or infer that a target CoreDNS instance exposes DNS-over-QUIC, often via UDP/853 or a configured DoQ listener.
2. Open QUIC connections to the CoreDNS DoQ endpoint.
3. Create many QUIC streams over one or more connections.
4. Send exactly one byte on each stream, leaving the DoQ length prefix incomplete.
5. Keep streams open so CoreDNS workers block indefinitely waiting for more data.
6. Continue opening streams until goroutine and memory growth exhaust available resources.
7. Cause CoreDNS to become unresponsive, restart, or be OOM-killed, disrupting DNS resolution.

How to detect it

Look for evidence of denial-of-service activity against CoreDNS DoQ endpoints and resulting process instability. Useful sources include CoreDNS logs, systemd or service-manager logs, kernel OOM logs, container-runtime logs, Kubernetes pod events, network flow records, firewall logs, load balancer telemetry, and host metrics. Investigate sudden memory growth in CoreDNS, increasing goroutine counts if exported, DNS timeout spikes, repeated restarts, OOM-kill events, or traffic bursts to UDP/853 from one or a small set of remote IPs. Network telemetry may show long-lived or high-rate QUIC sessions with many streams but little application payload. Because the exploit can consist of incomplete one-byte stream data, application logs may be sparse; absence of DNS query logs does not rule out exploitation. Correlate restart or OOM events with inbound UDP/853 activity and unusual DNS-over-QUIC connection patterns.

• OOMKilled
• Killed process
• Out of memory: Killed process
• oom-kill
• signal: killed
• exit code 137
• coredns
• udp/853
• UDP/853
• quic://
• io.ReadFull
• read: connection reset by peer
• context deadline exceeded
• plugin/errors
• CoreDNS-1.14.2
• CoreDNS-1.14.1
• CoreDNS-1.14.0

What your security team should do

• Inventory all CoreDNS deployments and identify instances exposing DNS-over-QUIC, especially listeners reachable from untrusted networks.
• Upgrade affected CoreDNS instances to version 1.14.3 or later as the primary remediation.
• Prioritize internet-facing or cross-tenant/shared DNS infrastructure because unauthenticated remote exploitation can cause service-wide DNS outages.
• If patching is delayed, restrict or disable DNS-over-QUIC exposure and apply UDP/853 filtering or rate limits at network boundaries.
• Monitor CoreDNS memory, goroutine count, restart count, DNS latency, and SERVFAIL/timeout rates for signs of active exploitation or stress.
• Review logs and runtime events from the period since publication for unexplained CoreDNS OOM kills, restarts, or sudden memory growth.
• Add alerting for repeated CoreDNS restarts, Kubernetes OOMKilled events, and high-volume QUIC/UDP traffic to DoQ listeners.