CVE-2026-82399

What it actually does

On DNS-over-HTTPS, DNS-over-HTTP/3, DNS-over-QUIC, and DNS-over-gRPC request paths, CoreDNS unpacks attacker-controlled DNS section counts before dns.DefaultMsgAcceptFunc validates the fixed header. Name compression plus inflated section counts can amplify heap allocation before the plugin chain runs, so plugin-level rate limiting cannot bound concurrent requests. The result is process-wide memory exhaustion and termination of CoreDNS. Ordinary UDP and TCP listeners are not affected because they validate the header first. Confidentiality and integrity are not impacted; availability of the resolver process is.

Why it matters to the business

Workloads that depend on the affected CoreDNS instance can lose name resolution until the process is restarted, which commonly shows up as failed service discovery, application timeouts, and cluster or site outages rather than data theft. Encrypted-DNS endpoints that are reachable without authentication are the operational exposure; UDP/TCP-only deployments are not vulnerable to this issue. The flaw is not in CISA KEV, has no reported ransomware use, and published exploit maturity is none, but it has been public for 17 days, is remotely triggerable without credentials, and scores as high availability impact (CVSS 7.5), so production resolvers should still be patched promptly.

How an attack unfolds

An unauthenticated remote client targets a CoreDNS listener that speaks DoH, HTTP/3, QUIC, or gRPC. The client submits DNS messages whose section counts and compression pointers cause unpacking to allocate far more memory than the on-wire size suggests. Unpacking occurs before header acceptance and before plugins, so request-rate controls in the plugin chain never see the traffic. Repeating this concurrently drives the process to out-of-memory termination and denies DNS service until operators restart CoreDNS. UDP and TCP paths cannot be used for this technique.

How to fix it

Upgrade CoreDNS to 1.14.7 or later, which unpacks encrypted-DNS messages only after the fixed header is accepted. If an immediate upgrade is not possible, disable or do not expose DoH, DNS-over-HTTP/3, DNS-over-QUIC, and DNS-over-gRPC listeners; keep serving UDP/TCP DNS, which are not affected. Restrict remaining encrypted-DNS listeners with network controls and mutual TLS so they are not reachable by untrusted clients. Process memory limits and orchestrator restart policies contain blast radius but do not prevent denial of service, because the process can still be driven to exit.

How to confirm the fix worked

Confirm every CoreDNS binary and image reports 1.14.7 or newer. Inventory Corefile and deployment manifests for https, quic, and grpc server blocks and for DoH-related plugins. After upgrade, verify legitimate encrypted-DNS clients still resolve, and that the running process no longer unpacks messages before header acceptance on those paths. Treat any remaining pre-1.14.7 instance with encrypted-DNS listeners as exposed.

Typical attack path

1. Identify a CoreDNS deployment with DoH, DNS-over-HTTP/3, DNS-over-QUIC, or DNS-over-gRPC enabled and reachable from the attacker network.
2. Send unauthenticated encrypted DNS requests that trigger unpacking of messages with excessive section counts and DNS name compression before header validation.
3. Issue many such requests in parallel so allocations accumulate before plugin-level rate limiting.
4. Cause CoreDNS memory exhaustion, process crash or OOM kill, and loss of DNS resolution until the service is restarted.

How to detect it

There is no public exploit maturity and no named threat actors tied to this issue, so look for operational artifacts rather than a known payload. Correlate CoreDNS process exits, Kubernetes/container OOMKilled events, and host oom-killer messages with traffic to encrypted-DNS listeners (typically DoH on HTTPS, DNS-over-QUIC, and gRPC). Hunt for sudden memory growth of the CoreDNS process without a matching rise in legitimate query volume, repeated restart loops, and bursts of connections on DoH/QUIC/gRPC endpoints shortly before the crash. UDP/TCP query logs alone will not show this attack. Absence of these signals does not prove non-exploitation if the process was restarted and logs rotated.

• oom-kill.*coredns
• Killed process .* \(coredns\)
• reason:OOMKilled
• coredns.service: Main process exited
• container.*coredns.*OOMKilled

What your security team should do

• Patch all CoreDNS instances to 1.14.7 or later as the primary control.
• Inventory where DoH, DNS-over-HTTP/3, DNS-over-QUIC, or DNS-over-gRPC is enabled and remove or firewall those listeners if they are not required.
• Prioritize internet-facing and cluster-ingress resolvers; UDP/TCP-only CoreDNS is not affected by this issue.
• Apply memory limits and liveness probes so a crash is contained and auto-recovered, understanding this is not a fix.
• Watch for CoreDNS OOM kills and restart storms on encrypted-DNS ports until the fleet is upgraded.