CVE-2025-68151: 
NixOS vulnerability analysis and mitigation

CVE-2025-68151 is a resource exhaustion (Denial of Service) vulnerability in CoreDNS affecting its gRPC, HTTPS, and HTTP/3 server implementations. Prior to version 1.14.0, these servers lack critical resource-limiting controls — including connection limits, stream limits, and message size constraints — allowing an unauthenticated remote attacker to exhaust server memory and crash or degrade the DNS service. The vulnerability was disclosed on January 8, 2026, and is similar in nature to CVE-2025-47950 (QUIC DoS) but affects additional server types. It carries a CVSS v3.1 base score of 7.5 (High) and a CVSS v4.0 score of 6.6 (Medium) (GitHub Advisory, NVD).

The root cause is classified as CWE-770 (Allocation of Resources Without Limits or Throttling). Two distinct attack surfaces exist: (1) the gRPC, HTTPS, and HTTP/3 servers do not enforce upper bounds on concurrent connections or active streams, allowing an attacker to open many parallel connections and rapidly issue requests until memory is exhausted; and (2) the gRPC server accepts arbitrarily large protobuf messages (up to the default ~4 MB gRPC limit) without validating against the DNS protocol's 64 KB maximum message size, enabling rapid memory exhaustion via concurrent oversized messages. The patch in commit 0d8cbb1 introduces netutil.LimitListener for connection limiting, grpc.MaxConcurrentStreams and message size limits for gRPC, and MaxIncomingStreams for HTTP/3, with secure defaults of 256 max streams and 200 max connections (GitHub Advisory, Patch Commit).

Successful exploitation results in memory exhaustion on the CoreDNS server, causing service degradation or a complete crash (OOM kill), with a high availability impact and no confidentiality or integrity impact. Testing referenced in the advisory demonstrates that even modest resource configurations (e.g., 256 MB RAM) can be exhausted quickly by scaling concurrency parameters. In Kubernetes and cloud-native environments where CoreDNS serves as the cluster DNS resolver, a crash would disrupt all DNS-dependent workloads, potentially causing widespread service outages and lateral availability failures across the cluster (GitHub Advisory).

There is no public proof-of-concept exploit code and no evidence of in-the-wild exploitation at this time (GitHub Advisory). The EPSS score is approximately 0.122%, indicating a low probability of exploitation in the near term. The vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. No threat actor attribution has been reported. The attack requires no authentication, no user interaction, and low complexity, making it straightforward to exploit if a public PoC were to emerge.

1. Reconnaissance: Identify CoreDNS instances running versions prior to 1.14.0 that expose gRPC (port 443 or custom), HTTPS (DoH), or HTTP/3 (DoH3) endpoints — these can be discovered via network scanning tools like Nmap or Shodan targeting known CoreDNS ports.
2. Connection flooding (gRPC/HTTPS/HTTP3): Open a large number of concurrent TCP/TLS connections to the target CoreDNS server's gRPC or HTTPS endpoint without enforcing any rate limiting. Tools such as grpc-bench, h2load, or custom scripts can be used to rapidly open hundreds of parallel connections.
3. Stream exhaustion: For gRPC and HTTP/3 targets, open many concurrent streams per connection (e.g., using gRPC streaming calls or QUIC multi-stream clients) to multiply resource consumption beyond connection-level limits.
4. Oversized message attack (gRPC): Send multiple concurrent gRPC DNS requests with protobuf payloads exceeding the DNS protocol's 64 KB limit (up to the gRPC default ~4 MB), causing the server to allocate large memory buffers for each request.
5. Memory exhaustion: Sustain the flood of connections, streams, or oversized messages until the CoreDNS process's memory is exhausted, triggering OOM termination or severe performance degradation, resulting in DNS service unavailability (GitHub Advisory, Patch Commit).

• Network: Sudden spike in concurrent TCP/TLS connections to CoreDNS gRPC (typically port 443) or HTTPS/HTTP3 endpoints from one or multiple source IPs; unusually high volume of gRPC or HTTP/2 streams from a single client.
• Process: CoreDNS process memory usage growing rapidly toward system limits; OOM killer events in system logs referencing the CoreDNS process (coredns binary).
• Logs: CoreDNS error logs showing repeated connection or stream rejections; system logs (/var/log/syslog, dmesg) containing Out of memory: Kill process entries for CoreDNS; Kubernetes pod logs showing repeated CoreDNS pod restarts (CrashLoopBackOff).
• Metrics: Prometheus/CoreDNS metrics showing abnormal spikes in coredns_dns_requests_total or connection count metrics; memory utilization metrics for the CoreDNS pod/process approaching container or system limits.

Upgrade CoreDNS to version 1.14.0 or later, which introduces configurable resource limits with secure defaults (256 max streams, 200 max connections) for gRPC, HTTPS, and HTTP/3 servers (GitHub Advisory, Patch Commit). Microsoft has also released patches for affected Azure Linux (AZL3) and CBL-Mariner 2 CoreDNS packages. As interim mitigations, implement network-level controls such as firewall rules to restrict access to CoreDNS gRPC/HTTPS/HTTP3 endpoints from untrusted networks, apply connection rate limiting at the load balancer or ingress layer, and monitor CoreDNS memory usage and connection counts for anomalies.

The vulnerability was reported by security researcher thevilledev, who also authored the fix via GitHub pull request #7490 (PR #7490). The CoreDNS maintainers published the advisory and patch promptly on January 8, 2026. Microsoft acknowledged the issue and issued patches for their Azure Linux CoreDNS packages. No significant broader media coverage or notable community debate has been identified beyond standard vulnerability tracking and distribution advisories.