CVE-2025-47950: CoreDNS DNS-over-QUIC DoS Vulnerability

CVE-2025-47950 Overview

CVE-2025-47950 is a Denial of Service (DoS) vulnerability in the CoreDNS DNS-over-QUIC (DoQ) server implementation. In versions prior to 1.12.2, the server 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 exploit this by opening a large number of streams, leading to uncontrolled memory consumption and eventually causing an Out Of Memory (OOM) crash — particularly impactful in containerized or memory-constrained environments.

Critical Impact

Remote unauthenticated attackers can cause complete service disruption by exhausting server memory through unlimited QUIC stream creation, leading to OOM crashes in CoreDNS deployments.

Affected Products

• CoreDNS versions prior to 1.12.2
• CoreDNS deployments with DNS-over-QUIC (quic://) enabled
• Containerized CoreDNS instances with memory constraints

Discovery Timeline

• 2025-06-06 - CVE-2025-47950 published to NVD
• 2025-08-15 - Last updated in NVD database

Technical Details for CVE-2025-47950

Vulnerability Analysis

This vulnerability falls under CWE-770 (Allocation of Resources Without Limits or Throttling). The CoreDNS DNS-over-QUIC server implementation followed a 1:1 stream-to-goroutine model, meaning every incoming QUIC stream spawned a dedicated goroutine for processing. Without any limits on concurrent streams or total goroutines, the server was susceptible to resource exhaustion attacks.

The QUIC protocol, as defined in RFC 9250, supports multiplexed streams over a single connection. While this design improves performance under normal conditions, it creates an attack surface when stream limits are not enforced. An attacker can rapidly open thousands of streams, each consuming memory for its associated goroutine, until the server exhausts available memory.

This attack is particularly devastating in Kubernetes environments where CoreDNS commonly runs as the cluster DNS provider. Memory limits imposed by container orchestration will cause the CoreDNS pod to be OOM-killed, disrupting DNS resolution for the entire cluster.

Root Cause

The root cause is the absence of resource throttling in the QUIC stream handling logic. The server accepted and processed an unlimited number of concurrent QUIC streams, allocating a new goroutine for each stream without any cap. This unbounded resource allocation pattern is a classic resource exhaustion vulnerability.

Attack Vector

The attack is network-based and requires no authentication or user interaction. An attacker can exploit this vulnerability by:

1. Establishing a QUIC connection to a CoreDNS server with DoQ enabled
2. Rapidly opening a large number of QUIC streams on the connection
3. Each stream triggers goroutine allocation on the server
4. Memory consumption grows unbounded until OOM occurs

The patch in version 1.12.2 introduces two key mitigation mechanisms as shown in the security fix:

// TLSConfig when listening for encrypted connections (gRPC, DNS-over-TLS).
TLSConfig *tls.Config

// MaxQUICStreams defines the maximum number of concurrent QUIC streams for a QUIC server.
// This is nil if not specified, allowing for a default to be used.
MaxQUICStreams *int

// MaxQUICWorkerPoolSize defines the size of the worker pool for processing QUIC streams.
// This is nil if not specified, allowing for a default to be used.
MaxQUICWorkerPoolSize *int

// Timeouts for TCP, TLS and HTTPS servers.
ReadTimeout  time.Duration
WriteTimeout time.Duration

Source: CoreDNS Commit Details

The fix introduces max_streams (default: 256) to cap concurrent QUIC streams per connection and worker_pool_size (default: 1024) to implement a bounded worker pool, eliminating the 1:1 stream-to-goroutine model.

Detection Methods for CVE-2025-47950

Indicators of Compromise

• Unusual memory growth patterns on CoreDNS processes
• High goroutine counts observed via pprof or runtime metrics
• CoreDNS pods being OOM-killed repeatedly in Kubernetes environments
• Abnormally high number of QUIC connections from single source IPs

Detection Strategies

• Monitor CoreDNS memory usage and set alerts for rapid consumption increases
• Track goroutine counts via Go runtime metrics exposed through Prometheus
• Implement network monitoring to detect anomalous QUIC connection patterns
• Review container orchestrator logs for OOM kill events targeting CoreDNS

Monitoring Recommendations

• Enable CoreDNS metrics plugin and export to a monitoring system
• Configure memory-based alerting thresholds before container limits are reached
• Implement rate limiting at the network layer for QUIC traffic to DNS servers
• Use distributed tracing to correlate DNS availability issues with memory events

How to Mitigate CVE-2025-47950

Immediate Actions Required

• Upgrade CoreDNS to version 1.12.2 or later immediately
• If unable to upgrade, disable DNS-over-QUIC by removing or commenting out quic:// blocks in Corefile
• Apply container runtime resource limits to detect and isolate excessive memory usage
• Implement network-level rate limiting for QUIC connections to CoreDNS

Patch Information

The patch is available in CoreDNS version 1.12.2. The fix introduces two configuration options: max_streams (default 256) caps concurrent QUIC streams per connection, and worker_pool_size (default 1024) implements a server-wide bounded worker pool for stream processing. Review the GitHub Security Advisory and the CoreDNS Commit Details for complete details.

Workarounds

• Disable QUIC support by removing or commenting out the quic:// block in the Corefile
• Use container runtime resource limits to detect and isolate excessive memory usage
• Monitor QUIC connection patterns and configure alerts on anomalies
• Consider using DNS-over-TLS or DNS-over-HTTPS as alternatives until upgrade is possible

# Corefile configuration example - disable QUIC by commenting out
# .:5853 {
#     tls /path/to/cert.pem /path/to/key.pem
#     forward . 8.8.8.8
#     quic://
# }

# Use DoT instead while awaiting upgrade
.:853 {
    tls /path/to/cert.pem /path/to/key.pem
    forward . 8.8.8.8
}