CoreDNS rewrite Plugin Remote DoS via Nil-Pointer Panic (CVE-2020-8229)

Vulnerability Overview Vulnerability Name: rewrite-plugin EDNS0 response-revert nil-pointer panic (remote DoS) when a downstream plugin returns a response with no OPT record Vulnerability Description: CoreDNS's plugin supports EDNS0 rewrite rules with an optional flag. When is set, the plugin queues a "response rule" that runs on the downstream plugin's reply to restore the client's original EDNS0 options. Two response rules, and , call and immediately dereference the returned (reading ) without a nil check. If returns nil (which is common for authoritative responses lacking an OPT record), does not copy the request's OPT. Plugins such as , , , , answer plugins, and any handler building a fresh response typically do not include an OPT record in such responses. When such an OPT-less response passes through the , the response rule dereferences a nil , causing a panic. Trigger Conditions: The trigger is remote and unauthenticated: a single standard DNS query (no EDNS0 required in the request) — the append operation adds to a copy of the request. In default deployments, CoreDNS captures the via and converts it to SERVFAIL, so the actual impact is that each matching query crashes into SERVFAIL, plus panic overhead — resulting in a remote availability degradation for the affected query class. If the operator enables the supported directive (which deliberately disables panic recovery), the same queries will crash the entire CoreDNS process. Scope Affected Versions: <= 1.14.4 Fixed Version: 1.14.5 CVSS v3 Base Metrics: - Attack Vector: Network - Attack Complexity: Low - Privileges Required: None - User Interaction: None - Scope: Unchanged - Confidentiality: None - Integrity: None - Availability: Low CVE ID: CVE-2020-8229 Weakness: CVE-476 Remediation Add nil checks to the two response revert rules so that responses without an OPT record become no-ops instead of causing a panic. POC Code Observed Panic and Call Chain Attacker Model / Preconditions The attacker is any client capable of sending DNS queries to the resolver (unauthenticated, network-reachable; no EDNS0 required in the query). Deployment preconditions require operator configuration: CoreDNS must contain a rule (the keyword is the trigger; it is a documented, common option whose sole purpose is to restore the client's EDNS0 state). The second condition — the downstream response lacking an OPT record — is satisfied by standard authoritative services: does not copy the request's OPT, and many built-in plugins ( , , , , answer plugins) and fallbacks of the rewrite plugin (SetNoError path) produce responses without an OPT unless explicitly added by the downstream plugin. No special record content or oversized inputs are required. Impact Remote, unauthenticated clients can force every matching query into a panic within the response-revert path of the plugin. In a default ( ) configuration, this renders the affected query class unavailable (continuous SERVFAILs and panic overhead exceed one packet); if the operator enables panic recovery via , a single crashed standard query will crash the entire CoreDNS instance — in Kubernetes, this constitutes cluster DNS, meaning one crashed node renders DNS unavailable for the entire cluster. This bug requires no spoofing, oversized payloads, nor control over upstream sources; the OPT-less responses originate from CoreDNS's official authoritative plugins. Proof of Concept (Complete — Run Only on 127.0.0.1) The PoC is a self-contained Go test placed within the CoreDNS modules. It drives the real endpoint: a standard query (no EDNS0) hits a rule, the request is forwarded to a minimal downstream handler which returns a response without an OPT record (similar to / / / / -answer plugins), and the queued panics in . A negative control with disabled proves that when no response rule is queued, downstream responses are handled correctly. Remediation Advice Add nil checks to the two response revert rules so that responses without an OPT record become no-ops instead of causing a panic. These rules only delete or replace existing options, so returning early when there is no OPT is semantically correct (there is nothing to revert). As a defense-in-depth measure, consider wrapping to panic if a single response rule fails to take over request handling, and audit other implementations for the same unchecked dereference patterns. Credits to Sudor / Tarmo Technologies.

Goal Reached Thanks to every supporter — we hit 100%!

CoreDNS rewrite Plugin Remote DoS via Nil-Pointer Panic (CVE-2020-8229)

More from this source