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
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.
References
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
server_quic.go
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:These defaults are generous and aligned with typical DNS-over-QUIC client behavior.
Workarounds
If you're unable to upgrade immediately, you can:
quic://
block in your CorefileReferences
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.
References