CVE-2025-68151 Overview
CVE-2025-68151 is a resource exhaustion vulnerability in CoreDNS, a popular DNS server that chains plugins commonly used in Kubernetes environments and cloud-native infrastructure. Prior to version 1.14.0, multiple CoreDNS server implementations including gRPC, HTTPS, and HTTP/3 lack critical resource-limiting controls. An unauthenticated remote attacker can exhaust memory and degrade or crash the server by opening many concurrent connections, streams, or sending oversized request bodies.
Critical Impact
This vulnerability enables remote attackers to cause denial of service conditions against CoreDNS servers without authentication, potentially disrupting critical DNS resolution services in containerized and cloud environments.
Affected Products
- CoreDNS versions prior to 1.14.0
- CoreDNS gRPC server implementation
- CoreDNS HTTPS and HTTP/3 (QUIC) server implementations
Discovery Timeline
- 2026-01-08 - CVE-2025-68151 published to NVD
- 2026-01-08 - Last updated in NVD database
Technical Details for CVE-2025-68151
Vulnerability Analysis
This vulnerability (CWE-770: Allocation of Resources Without Limits or Throttling) affects the CoreDNS server's handling of concurrent connections and streams across multiple transport protocols. The issue is similar in nature to CVE-2025-47950, which addressed QUIC DoS vulnerabilities, but extends to additional server types including gRPC and HTTPS that did not enforce connection limits, stream limits, or message size constraints.
The vulnerability allows attackers to open numerous concurrent connections or streams without any server-side throttling, leading to memory exhaustion. Additionally, the lack of message size constraints permits oversized request bodies that can further accelerate resource depletion.
Root Cause
The root cause stems from missing resource-limiting controls in the CoreDNS server implementations. Specifically, the configuration structures lacked parameters for:
- Maximum concurrent gRPC streams per connection
- Maximum concurrent gRPC connections
- Maximum concurrent HTTPS connections
- Maximum concurrent QUIC streams for HTTPS/3
Without these limits, the server accepts unbounded resource allocation requests, making it susceptible to exhaustion attacks.
Attack Vector
The attack can be executed remotely over the network by an unauthenticated attacker. The attacker can target any exposed CoreDNS server endpoint (gRPC, HTTPS, or HTTP/3) and:
- Open a large number of concurrent connections simultaneously
- Create excessive streams within established connections
- Send oversized DNS request payloads exceeding normal message boundaries
This forces the server to allocate memory for each connection/stream without recourse, eventually exhausting available resources and causing service degradation or crashes.
// Security patch adds resource limiting configuration parameters
// Source: https://github.com/coredns/coredns/commit/0d8cbb1a6bcb6bc9c1a489865278b8725fa20812
// This is nil if not specified, allowing for a default to be used.
MaxQUICWorkerPoolSize *int
+ // MaxGRPCStreams defines the maximum number of concurrent streams per gRPC connection.
+ // This is nil if not specified, allowing for a default to be used.
+ MaxGRPCStreams *int
+
+ // MaxGRPCConnections defines the maximum number of concurrent gRPC connections.
+ // This is nil if not specified, allowing for a default to be used.
+ MaxGRPCConnections *int
+
+ // MaxHTTPSConnections defines the maximum number of concurrent HTTPS connections.
+ // This is nil if not specified, allowing for a default to be used.
+ MaxHTTPSConnections *int
+
+ // MaxHTTPS3Streams defines the maximum number of concurrent QUIC streams for HTTPS3.
+ // This is nil if not specified, allowing for a default to be used.
+ MaxHTTPS3Streams *int
+
// Timeouts for TCP, TLS and HTTPS servers.
ReadTimeout time.Duration
WriteTimeout time.Duration
The patch also introduces default limits and message size constraints in the gRPC server implementation:
// Default resource limits introduced in server_grpc.go
// Source: https://github.com/coredns/coredns/commit/0d8cbb1a6bcb6bc9c1a489865278b8725fa20812
const (
// maxDNSMessageBytes is the maximum size of a DNS message on the wire.
maxDNSMessageBytes = dns.MaxMsgSize
// maxProtobufPayloadBytes accounts for protobuf overhead.
// Field tag=1 (1 byte) + length varint for 65535 (3 bytes) = 4 bytes total
maxProtobufPayloadBytes = maxDNSMessageBytes + 4
// DefaultGRPCMaxStreams is the default maximum number of concurrent streams per connection.
DefaultGRPCMaxStreams = 256
// DefaultGRPCMaxConnections is the default maximum number of concurrent connections.
DefaultGRPCMaxConnections = 200
)
Detection Methods for CVE-2025-68151
Indicators of Compromise
- Abnormally high number of concurrent connections to CoreDNS gRPC, HTTPS, or HTTP/3 endpoints
- Memory utilization spikes on CoreDNS server instances without corresponding legitimate traffic increases
- CoreDNS process crashes or restarts due to out-of-memory conditions
- DNS resolution failures or increased latency across services relying on affected CoreDNS instances
Detection Strategies
- Monitor CoreDNS connection counts and compare against baseline thresholds for anomaly detection
- Implement alerting on memory utilization metrics for CoreDNS pods/processes exceeding normal operational ranges
- Review CoreDNS logs for connection handling errors or resource exhaustion messages
- Deploy network-level monitoring to detect connection flooding patterns targeting DNS server ports
Monitoring Recommendations
- Configure Prometheus metrics collection for CoreDNS with alerts on coredns_dns_requests_total anomalies
- Monitor Kubernetes pod restart counts for CoreDNS deployments
- Implement connection rate limiting at the network layer as an additional defense layer
- Set up dashboards tracking concurrent connection counts by protocol type (gRPC, HTTPS, HTTP/3)
How to Mitigate CVE-2025-68151
Immediate Actions Required
- Upgrade CoreDNS to version 1.14.0 or later immediately
- Review and configure appropriate connection and stream limits in CoreDNS configuration
- Implement network-level rate limiting for DNS server endpoints as a temporary measure
- Monitor CoreDNS instances for signs of exploitation while planning upgrades
Patch Information
CoreDNS version 1.14.0 contains the security patch that introduces resource-limiting controls for gRPC, HTTPS, and HTTP/3 server implementations. The patch adds configurable parameters for maximum connections, streams, and enforces message size constraints.
For detailed patch information, refer to:
Workarounds
- Deploy network firewalls or load balancers with connection rate limiting in front of CoreDNS
- Restrict access to CoreDNS gRPC, HTTPS, and HTTP/3 endpoints to trusted networks only
- Implement resource quotas and limits for CoreDNS pods in Kubernetes environments
- Consider temporarily disabling unused server protocols (gRPC, HTTPS, HTTP/3) if not required
# Example: Configure resource limits for CoreDNS in Kubernetes
# Add to CoreDNS deployment specification
kubectl patch deployment coredns -n kube-system --type='json' -p='[
{
"op": "add",
"path": "/spec/template/spec/containers/0/resources",
"value": {
"limits": {
"memory": "256Mi",
"cpu": "200m"
},
"requests": {
"memory": "128Mi",
"cpu": "100m"
}
}
}
]'
Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.

