CoreDNS has been assigned CVE-2026-26018 — a high-severity denial-of-service vulnerability in the
loop plugin that can be triggered remotely by an attacker who can send carefully crafted DNS queries and (under realistic cluster conditions) crash the CoreDNS process, with wide-reaching implications for Kubernetes clusters and any infrastructure that uses CoreDNS for in-cluster name resolution. (
github.com)
Background
CoreDNS is widely deployed as the default DNS server inside Kubernetes clusters and as a standalone DNS server in many cloud and on‑prem environments. Its design is plugin-based: each plugin handles a focused behavior such as forwarding, caching, rewrite, and loop detection. The
loop plugin exists to protect resolvers from forwarding loops by self-testing at startup and during certain error conditions. The CoreDNS project published an advisory and issued a patch in release 1.14.2 to address a predictable-randomness and process-termination issue in that plugin. (
github.com)
Core technical facts confirmed by the maintainers and by NVD:
- Vulnerability: Denial of Service (process crash) in the
loop plugin. (github.com)
- Root cause: Use of Go's non-cryptographic PRNG (
math/rand) seeded with a predictable value (time.Now().UnixNano()), making the plugin's “secret” query name guessable. Paired with a fatal exit path (log.Fatalf() → os.Exit(1)), this allows an attacker to cause immediate process termination. (github.com)
- Affected versions: CoreDNS prior to
1.14.2. Patched in 1.14.2 (released March 6, 2026). (github.com)
- CVSS: the GitHub CNA assigned a CVSS v3.1 base score of 7.5 (High) with vector
AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H. (nvd.nist.gov)
What went wrong: predictable randomness and fatal failure
The two failure modes that combine into an exploitable condition
This vulnerability is textbook composed-failure: two independent design choices create a chain that lets a remote attacker bring down the entire server.
- Predictable PRNG seed: using
math/rand seeded with time.Now().UnixNano() produces values that are effectively guessable if the attacker can observe or infer the approximate server start time or the self-test query that the plugin emits to prove liveness. The plugin uses two consecutive r.Int() calls to build the “secret” qname it queries against itself. Because the seed is based on a timestamp, an attacker with coarse timing information can compute the same outputs. (github.com)
- Fatal error path: the plugin counts matching HINFO responses and if it sees three or more, it treats this as evidence of a forwarding loop and calls
log.Fatalf(), which logs and then calls os.Exit(1). That immediate process termination is why this is not a per-request failure but an availability-critical shutdown. A safer design would have used process-level recovery, an alert and graceful failover, or at minimum a non-fatal countermeasure. (github.com)
Combining these two flaws, an attacker who can either read CoreDNS logs (for example, via shared logging in a multi-tenant cluster or a compromised pipeline) or otherwise infer the qname can send three matching HINFO queries and trigger an immediate exit. The exploit requires network access to the DNS server and either direct log access or the opportunity to observe the self-test during a window of time. (
github.com)
Why this is practically exploitable
The advisory highlights realistic windows that increase exploitation feasibility:
- During normal startup the self-test window is short (on the order of seconds) and requires precise timing.
- When upstream resolvers are unreachable (network partition, misconfiguration, or transient outage), the self-test retries extend the window to tens of seconds — a time when many clusters log repeated HINFO self-tests and therefore leak the qname via routine logging. Under those conditions the advisory rates attack feasibility as high. (github.com)
The risk grows in Kubernetes and managed environments where logging is centralized and many actors (controllers, cloud services, CI/CD, or other tenants) can access aggregated logs.
Who and what is affected
- CoreDNS versions older than
1.14.2 are explicitly listed as vulnerable. This includes upstream CoreDNS releases used by:
- Kubernetes clusters that run the default CoreDNS deployment.
- Container images, appliance images, and third-party products embedding CoreDNS (for example, CNI vendors, Kubernetes distributions, and cloud‑provider managed Kubernetes stacks) that had not already rolled the patch. (nvd.nist.gov)
- The vulnerability is not a code-execution or data-exfiltration bug; the impact is availability. A crashed CoreDNS instance disrupts DNS inside the cluster, which in turn affects service discovery, API access, and many operator workflows. The advisory highlights cascaded service failures and potential crash-restart loops that make recovery non-trivial for heavily automated platforms. (github.com)
Caveat: Not every deployment of CoreDNS exposes the
loop plugin (it must be enabled in the Corefile), and not every environment exposes logs or has upstream conditions that extend the self-test window. Operators should therefore verify both the CoreDNS version and their Corefile configuration to determine true exposure. The advisory and NVD both emphasize that the plugin must be present and active for the vulnerability to be relevant. (
github.com)
The fix: what changed in 1.14.2
CoreDNS released version
1.14.2 on March 6, 2026. The release notes and advisory show the corrective action: replace the
math/rand usage with a cryptographically secure generator from
crypto/rand when generating the self-test
qname, and avoid the unsafe
log.Fatalf() termination path in circumstances where a non-fatal response would be sufficient. The release explicitly lists “Use crypto/rand for query name generation” as the fix. (
github.com)
Replacing
math/rand with
crypto/rand closes the predictability gap because
crypto/rand produces values that are not feasibly reproducible by an attacker, even with precise timing. The patch also adjusts how loop detection failures are handled so that a malicious actor cannot induce immediate process termination simply by guessing a short-lived name. (
github.com)
Cross-verification and community tracking
This CVE was published to the NVD and recorded by vulnerability trackers shortly after the CoreDNS advisory and release. Multiple independent trackers (NVD, GitHub advisory, Snyk, Tenable) show consistent descriptions, affected versions, and the remediation path. The NVD entry enumerates CWE-337 (Predictable PRNG seed) plus resource and allocation weaknesses, and it reflects the GitHub CNA CVSS score of 7.5. Security vendors’ feeds and vulnerability databases mirror this classification and point operators to upgrading to 1.14.2. (
nvd.nist.gov)
When multiple high-quality sources (vendor advisory + NVD + major scanners) align on the root cause and fix, that increases confidence in the technical narrative. Nevertheless, operators should still confirm their own supply-chain and distribution packaging (for example OS distro packages, container images, or embedded product bundles) to ensure a particular instance of CoreDNS has been updated — vendor packaging timelines can lag the upstream release.
Immediate actions for operators (prioritized)
- Upgrade first, test fast
- Upgrade all CoreDNS instances to
1.14.2 or later as the primary remediation. The upstream release contains the explicit fix and is the canonical remediation path. Verify the image/tag or package version in your environment and roll the update through your CI/CD and deployment processes. (github.com)
- If you cannot upgrade immediately, apply mitigations
- Disable the
loop plugin in your Corefile temporarily if your environment can tolerate the removal. This eliminates the vulnerable code path at the cost of losing automatic loop detection; document the change and plan a follow-up upgrade. Test before rolling to production.
- Restrict network access to the CoreDNS service: limit which clients can send UDP/TCP port 53 queries to your CoreDNS pods or instances via NetworkPolicies, security groups, firewall rules, or service mesh egress rules. If only trusted hosts can query the DNS endpoint, attack feasibility drops sharply. (github.com)
- Reduce logging exposure: if aggregated logs are visible to other tenants or public CI systems, consider temporarily tightening logging access controls to avoid leaking the self-test qname. This is a compensating control while you patch. (github.com)
- Harden process supervision and recovery semantics
- Ensure that your orchestration platform won’t immediately re-create a pod in a way that allows rapid crash loops to hide root causes. Use liveness/readiness probes wisely and set restart backoffs so that a targeted crash does not cause cascading platform instability. Consider adding resource and restart limits to slow forced restart loops and to give operators time to act.
- Confirm vendor-managed services
- If you rely on managed Kubernetes (for example, EKS/GKE/AKS) or vendor images that embed CoreDNS, consult the vendor advisory for their remediation schedule. Do not assume managed platforms have patched just because upstream released a fix. The timelines and attestation vary by vendor. (If you do not find a vendor advisory, contact your provider’s support channel.) (nvd.nist.gov)
Detection and hunting guidance
Effective detection requires looking for the two observable ingredients of an attack:
- Self-test HINFO queries in logs: the loop plugin’s self-test emits HINFO queries for the generated
qname. Search DNS logs, CoreDNS logs, and any aggregated logging for unusual HINFO queries or repetitive self-test patterns that include an odd qname consisting of numeric segments. Those entries may indicate either the self-test or an attacker observing it. (github.com)
- Sudden process terminations and crash timestamps: correlate CoreDNS process exits/crashes with network conditions (upstream timeouts, host-level outages). A suspicious sequence is repeated HINFO queries followed by
plugin/loop messages or abrupt exit messages around the same time. Watch for crash frequency suggesting an external trigger. (github.com)
Detection checklist:
- Search for
HINFO query types or plugin/loop log messages in your central logging stack.
- Query metrics for CoreDNS process restarts and short-lived pods across the last 24–72 hours.
- Check for log forwarding pipelines that expose CoreDNS logs publicly or to other tenants; if present, treat them as high-risk channels. (github.com)
Incident response: what to do if you see an exploit
- If you observe a CoreDNS crash that matches the advisory timeline: immediately isolate the affected node or pod from untrusted networks, collect logs (DNS queries, CoreDNS stderr/stdout, kubelet events, system journals), and preserve the failing Corefile and deployment manifest.
- Temporarily disable the
loop plugin (if feasible) to stop further immediate crashes, then plan a controlled upgrade to 1.14.2 with rolling restarts so cluster DNS does not suffer from a mass outage. Document all changes and retain audit trails.
- Hunt for post-exploit artifacts: look for any unexpected network scans or traffic that could indicate an attacker probing for the qname; verify whether any other components showed correlated events around the crash window. While this CVE is availability-only, the presence of an attacker capable of leveraging logs or timing suggests a broader breach or misconfiguration that should be investigated.
- Notify stakeholders: in multi-tenant clusters, inform tenants and compliance teams about observed exploitation because service discovery failures can mask or compound other incidents.
Longer-term risks and lessons learned
- Fail-safe engineering matters: using fatal process termination as an error-handling mechanism for a non-security failure (loop detection) is brittle. Production-facing infrastructure should fail gracefully wherever possible and avoid whole-process exits for recoverable or ambiguous conditions.
- Secrets should be secret: even ephemeral cryptographic secrets must be generated using non‑predictable sources. Using
math/rand for anything intended to be secret is a known anti-pattern; auditing code for similar uses (especially in plugins or extensions) can find other latent weaknesses.
- Observability trade-offs: centralized logging, while essential, increases risk when it leaks operational secrets (even short-lived ones). Developers and operators must balance visibility with the principle of least privilege for log access.
- Supply-chain verification: downstream packaging, distro maintainers, and container images sometimes lag upstream fixes. Track both upstream advisories and your platform/vendor advisories to ensure full remediation coverage.
Practical checklist (actionable)
- Verify version:
kubectl -n kube-system get deployment coredns -o yaml (or your distro equivalent) and confirm CoreDNS image/tag or package version is >= 1.14.2. If package-managed, check distro security advisories. (github.com)
- If upgrade is delayed: remove or comment out
loop from the Corefile, then reload CoreDNS after testing in staging.
- Add NetworkPolicy/Firewall rules to restrict port 53 access to trusted clients only. (github.com)
- Harden logging: ensure only authorized principals can read CoreDNS logs; rotate and audit log access. (github.com)
- Monitor: create alerts for CoreDNS restart counts, HINFO anomaly rates, and sudden increases in pod restarts. (github.com)
Final analysis and risk summary
CVE-2026-26018 is a high-impact availability flaw with a straightforward fix upstream. Its exploitability is driven by operational realities — extended self-test windows and centralized logging — rather than by a cryptographic break or remote code execution vector. The core lesson is that small implementation choices (predictable randomness; fatal exit paths) can yield outsized operational risk in cloud-native environments.
Operators should prioritize upgrading to CoreDNS
1.14.2 as the canonical fix. Where upgrades cannot be immediate, the mitigations above reduce risk materially. Given CoreDNS’s role as the backbone of in‑cluster discovery, even brief outages can have cascading consequences for microservices, automated controllers, and CI/CD pipelines; treat this as an urgent operational patch, not merely a routine dependency update. (
github.com)
If your inventory includes managed services, vendor-packaged images, or appliance software that embeds CoreDNS, verify vendor advisories and patch schedules instead of assuming vendor-side remediation. When public advisories and NVD entries align with upstream fixes, use them as your authoritative checklist — but always confirm in your own environment before marking the issue closed. (
nvd.nist.gov)
CoreDNS has moved quickly to patch the issue, but the window between vulnerability disclosure and full remediation across heterogeneous deployments is where attackers can cause maximum disruption. For infrastructure and platform teams, the immediate steps are simple and clear: verify, patch, and harden — and treat logging access and fatal-error behavior as first-class security considerations going forward. (
github.com)
Source: MSRC
Security Update Guide - Microsoft Security Response Center