CVE-2026-26018: 
NixOS vulnerability analysis and mitigation

CVE-2026-26018 is a Denial of Service vulnerability in CoreDNS's loop detection plugin that allows an unauthenticated remote attacker to crash the DNS server by sending specially crafted DNS queries. It affects all CoreDNS versions prior to 1.14.2 and was disclosed on March 6, 2026. The vulnerability stems from two design flaws: use of a predictable PRNG (seeded with time.Now().UnixNano()) for generating a secret query name, and a fatal error handler that calls os.Exit(1) upon detecting a perceived loop. It carries a CVSS v3.1 base score of 7.5 (High) (GitHub Advisory, Red Hat).

The root cause is classified under CWE-337 (Predictable Seed in PRNG) and CWE-400 (Uncontrolled Resource Consumption). The CoreDNS loop plugin generates a random query name (qname) at startup using Go's math/rand package seeded with time.Now().UnixNano(), making the qname predictable if an attacker can approximate the server's start time. The plugin sends an HINFO query to itself as a self-test; if it receives 3 or more matching HINFO queries, it invokes log.Fatalf() → os.Exit(1), immediately terminating the process. An attacker who can observe the qname (e.g., via CoreDNS logs in a shared Kubernetes cluster or centralized logging system) and send UDP packets to the CoreDNS port can trigger the crash with just three crafted HINFO queries. The exploitation window is significantly extended (up to 30 seconds) when the upstream DNS server is unreachable, as the loop plugin retries its self-test repeatedly (GitHub Advisory).

Successful exploitation results in complete unavailability of DNS resolution services — confidentiality and integrity are unaffected, but availability impact is high. Because CoreDNS is the default DNS server for Kubernetes clusters, a crash causes all in-cluster service discovery to fail, leading to cascading application-level failures across the cluster. If the attack is sustained, CoreDNS enters a crash-restart cycle, preventing recovery and prolonging the outage (GitHub Advisory).

A proof-of-concept exploit with a detailed attack timeline is publicly documented in the CoreDNS security advisory, including specific steps, query types (HINFO), and timing (GitHub Advisory). No authentication is required; the attacker only needs network access to the CoreDNS UDP port and the ability to observe the qname from logs. The EPSS score is approximately 0.04% (low probability of near-term exploitation), and there is no evidence of in-the-wild exploitation or CISA KEV catalog listing as of the time of disclosure (GitHub Advisory). Microsoft has also acknowledged the vulnerability in the context of Azure Linux distributions shipping affected CoreDNS versions (Microsoft MSRC).

1. Reconnaissance: Identify a target CoreDNS instance (version < 1.14.2) accessible over the network — particularly in Kubernetes environments where CoreDNS is the default DNS server.
2. Gain log access: Obtain access to CoreDNS logs via shared cluster access, centralized logging (e.g., Elasticsearch, Loki), or a compromised pod with log-reading permissions. This is common in multi-tenant Kubernetes clusters.
3. Induce network degradation: Optionally trigger or wait for a condition where the upstream DNS server is unreachable (network partition, misconfiguration, or outage). This extends the exploitation window to up to 30 seconds, during which the loop plugin retries its self-test.
4. Observe the qname: Monitor CoreDNS logs for the HINFO self-test query. The qname appears in log entries during each self-test attempt (e.g., <number1>.<number2>.<zone>).
5. Send crafted HINFO queries: Using a DNS tool (e.g., dig or a custom UDP packet sender), send 3 HINFO queries to the CoreDNS port (default UDP/53) with the observed qname:
   • T+5.1s: Send HINFO #1 → internal counter = 1
   • T+5.2s: Send HINFO #2 → internal counter = 2
   • T+5.3s: Send HINFO #3 → internal counter = 3 → os.Exit(1) triggered
6. Server crashes: CoreDNS immediately terminates, causing complete DNS resolution failure within the cluster (GitHub Advisory).

• Logs: CoreDNS log entries showing repeated HINFO queries for the same qname (format: <integer>.<integer>.<zone>) arriving in rapid succession from an external source; log entry Loop (<src> -> <dst>) detected for zone <zone> immediately before process termination.
• Process: Unexpected os.Exit(1) / abrupt CoreDNS process termination without a graceful shutdown signal; Kubernetes pod restart events for the CoreDNS pod (kubectl get events -n kube-system).
• Network: Burst of UDP DNS queries of type HINFO targeting the CoreDNS service IP, particularly queries matching the pattern <large-integer>.<large-integer>.<zone> from an unexpected source IP.
• File System / Kubernetes: Elevated CoreDNS pod restart count visible via kubectl get pods -n kube-system; CrashLoopBackOff state for CoreDNS pods if the attack is sustained (GitHub Advisory).

The primary remediation is to upgrade CoreDNS to version 1.14.2 or later, which replaces the predictable math/rand PRNG with crypto/rand for query name generation, eliminating the predictability flaw (CoreDNS Release). Microsoft has released updated packages for Azure Linux distributions (azl3_coredns and cbl2_coredns) (Microsoft MSRC). As a temporary workaround, restrict access to CoreDNS logs from untrusted principals and apply network policies to limit which sources can send DNS queries to the CoreDNS service port. Organizations running Kubernetes should prioritize this update given the critical role of CoreDNS in cluster DNS resolution and the public availability of PoC steps (Red Hat).

The vulnerability was covered in the context of Microsoft's March 2026 Patch Tuesday, which addressed 79 vulnerabilities including this CoreDNS issue affecting Azure Linux distributions (BleepingComputer via Bing). OpenSUSE issued security announcements for updated CoreDNS packages (OpenSUSE Security). Community reaction has been moderate, with the primary concern focused on the Kubernetes impact given CoreDNS's role as the default cluster DNS server.