GHSA-cvx7-x8pj-x2gw CoreDNS Vulnerable to DoQ Memory Exhaustion via Stream Amplification

• Go github.com/coredns/coredns: < 1.12.2 → fixed in 1.12.2

Summary A Denial of Service (DoS) vulnerability was discovered in the CoreDNS DNS-over-QUIC (DoQ) server implementation. The server previously created a new goroutine for every incoming QUIC stream without imposing any limits on the number of concurrent streams or goroutines. A remote, unauthenticated attacker could open a large number of streams, leading to uncontrolled memory consumption and eventually causing an Out Of Memory (OOM) crash — especially in containerized or memory-constrained environments. Impact • Component: `server_quic.go` • Attack Vector: Remote, network-based • Attack Complexity: Low • Privileges Required: None • User Interaction: None • Impact: High availability loss (OOM kill or unresponsiveness) This issue affects deployments with `quic://` enabled in the Corefile. A single attacker can cause the CoreDNS instance to become unresponsive using minimal bandwidth and CPU. Patches The patch introduces two key mitigation mechanisms: • `max_streams`: Caps the number of concurrent QUIC streams per connection. Default: `256`. • `worker_pool_size`: Introduces a server-wide, bounded worker pool to process incoming streams. Default: `1024`. This eliminates the 1:1 stream-to-goroutine model and ensures that CoreDNS remains resilient under high concurrency. The new configuration options are exposed through the `quic` Corefile block: ``` quic { max_streams 256 worker_pool_size 1024 } ``` These defaults are generous and aligned with typical DNS-over-QUIC client behavior. Workarounds If you're unable to upgrade immediately, you can: • Disable QUIC support by removing or commenting out the `quic://` block in your Corefile • Use container runtime resource limits to detect and isolate excessive memory usage • Monitor QUIC connection patterns and alert on anomalies References • RFC 9250 - DNS over Dedicated QUIC Connections • quic-go GitHub project • QUIC stream exhaustion class of vulnerabilities (related) Credit Thanks to @thevilledev for disclovering this vulnerability and contributing a high-quality fix. For more information Please consult our security guide for more information regarding our security process.