CVE-2026-82399: CoreDNS: Unauthenticated memory exhaustion in custom transports
CoreDNS is a DNS server written in Go. Prior to 1.14.7, the DNS-over-HTTPS, DNS-over-HTTP/3, DNS-over-QUIC, and DNS-over-gRPC request paths in plugin/pkg/doh/doh.go, core/dnsserver/serverquic.go, and core/dnsserver/servergrpc.go call dns.Msg.Unpack on attacker-controlled DNS section counts before dns.DefaultMsgAcceptFunc validates the fixed header. An unauthenticated client can use DNS name compression and excessive section counts to amplify allocation before the plugin chain, so plugin-level rate limiting cannot prevent concurrent requests from exhausting memory and terminating CoreDNS. The ordinary UDP and TCP listeners are not affected because they validate the header first. This issue is fixed in version 1.14.7.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
corednsto a version that resolves this vulnerability.Fixed in 1.14.7
Event History
Frequently Asked Questions
Which CoreDNS deployments are exposed?
Deployments running a version before 1.14.7 are exposed if they accept DNS-over-HTTPS, DNS-over-HTTP/3, DNS-over-QUIC, or DNS-over-gRPC requests. Ordinary UDP and TCP DNS listeners are not affected.
Does an attacker need credentials or interaction from a user?
No. An unauthenticated remote client can send crafted requests to an affected transport, with no privileges or user interaction required.
Will plugin-level rate limiting mitigate this issue?
No. The excessive allocation occurs before the plugin chain, so plugin-level rate limiting cannot prevent concurrent malicious requests from exhausting CoreDNS memory.
What is the remediation?
Upgrade CoreDNS to version 1.14.7. If an immediate upgrade is not possible, the provided information supports limiting exposure by not accepting requests through the affected custom transports; UDP and TCP listeners are not affected.