EUVD-2026-80989
GHSA-9gm5-9rfh-m6vx
Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessReach CoreDNS DoH/DoQ/gRPC listener
-
DeliverySend RFC 2136 UPDATE over that transport
-
ExploitBypassed accept-policy unpacks UPDATE
-
ExecutionProxy/forward relays to trusted upstream
-
PersistUpstream writes attacker records
-
ImpactDNS records altered, names hijacked
Vulnerability Assessment
| Weakness |
CWE
OWASP Top 10:2025
A01:2025 - Broken Access Control
ASVS 5.0
V4 - API and Web Service Proxy/intermediary controls
|
| Exploitation Conditions | Requires that CoreDNS (prior to 1.14.7) exposes at least one of the DNS-over-HTTPS, DNS-over-HTTP/3, DNS-over-QUIC, or DNS-over-gRPC listeners (these skip dns.DefaultMsgAcceptFunc, unlike UDP/TCP/DoT), AND that CoreDNS is configured with the proxy or forward plugin pointing at an RFC 2136 update-capable upstream, AND that the upstream trusts CoreDNS's source address/connection while NOT requiring an attacker-unknown end-to-end TSIG. Exploitation is unauthenticated and needs no user interaction, but is neutralized if only UDP/TCP/DoT transports are used, if there is no update-capable upstream, or if the upstream enforces TSIG - making the practical attack surface much narrower than the network-unauthenticated vector suggests. |
| Impact | The provided CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N, 7.5) frames this as a remotely reachable, unauthenticated integrity flaw, and PR:N/AV:N are consistent with the description (any client speaking DoH/DoH3/DoQ/gRPC to CoreDNS). However, the raw score overstates real-world risk because exploitation is heavily conditional: it only matters when CoreDNS proxies/forwards to an RFC 2136 update-capable upstream that trusts CoreDNS's source address/connection and does not enforce end-to-end TSIG. There is no EPSS score, no CISA KEV entry, and no public exploit in the supplied data - so this is a confused-deputy (CWE-441) design flaw fixed cleanly in code, not an actively-exploited threat. The confidentiality-labeled tag conflicts with the vector (C:N, I:H): the impact is DNS record tampering/zone takeover, an integrity/availability concern, not information disclosure. Net: a legitimate, well-scoped integrity bug worth patching promptly in CoreDNS instances exposing alternative DNS transports and forwarding to writable upstreams, but not an emergency for the majority of deployments that lack the update-capable-upstream precondition. |
| Exploit ScenarioDerived | An unauthenticated attacker sends a crafted RFC 2136 DNS UPDATE message over CoreDNS's DoH, DoH/3, DoQ, or DoT-over-gRPC listener, which - unlike the UDP/TCP/DoT paths - never applies dns.DefaultMsgAcceptFunc and therefore accepts an opcode it should reject. CoreDNS's proxy/forward plugin relays the UPDATE unchanged to an update-capable upstream that trusts CoreDNS's identity, causing records to be added, replaced, or deleted (traffic redirection, name takeover, mail-routing changes, or zone disruption). No public exploit code is identified at time of analysis, though the fixing commit and advisory precisely describe the mechanism. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Sep 16, 2026
Unauthenticated DNS UPDATE injection through CoreDNS's encrypted and gRPC listeners lets a remote client smuggle RFC 2136 dynamic-update messages into an upstream nameserver in CoreDNS versions prior to 1.14.7. The DNS-over-HTTPS, DNS-over-HTTP/3, DNS-over-QUIC, and DNS-over-gRPC code paths unpack queries without applying dns.DefaultMsgAcceptFunc, so they accept an opcode UPDATE that UDP, TCP, and DoT reject; when CoreDNS is running the proxy or forward plugin against an update-capable upstream that trusts CoreDNS's source address and does not require an attacker-unknown end-to-end TSIG, the UPDATE appears to come from CoreDNS itself and can add, replace, or delete records, hijack names, or alter mail routing in the writable zone. Exploitation is unauthenticated with no user interaction and no public exploit identified at time of analysis, but the exposed CVSS 7.5 (AV:N/AC:L) figure overstates practical reach: the assessed vector raises the bar to AC:H and S:C because the attacker must also find an update-capable upstream that trusts CoreDNS without TSIG enforcement, which substantially narrows the real attack surface.
RemediationAI
Upgrade to CoreDNS 1.14.7, the vendor-released fix version: the release at https://github.com/coredns/coredns/releases/tag/v1.14.7 contains commit 530b0a5ff2ad68cc0421f10dd93568945cc671c9, which routes all four affected listeners through the new dnsutil.UnpackRequest helper that applies dns.DefaultMsgAcceptFunc and rejects non-QUERY/NOTIFY opcodes such as RFC 2136 UPDATE. If upgrading immediately is not possible, apply the following compensating controls in order of effectiveness: enable TSIG on the upstream resolver so that any UPDATE lacking a valid, attacker-unknown end-to-end key is refused (this fully neutralizes the attack but requires shared-secret provisioning and key-rotation handling on both CoreDNS and the upstream, and breaks any existing unauthenticated forwarders); stop pointing the proxy or forward plugin at an update-capable upstream, or restrict the CoreDNS-to-upstream relationship so the upstream does not trust CoreDNS's source address for dynamic updates (trade-off: may require network re-segmentation or ACL changes at the upstream); and disable the DNS-over-HTTPS, DNS-over-HTTP/3, DNS-over-QUIC, and DNS-over-gRPC listeners, leaving only UDP/TCP/DoT, which already apply the request policy (trade-off: loses encrypted and HTTP-multiplexed client transports and may break DoH-only clients). Restricting network access to those listener ports to trusted client ranges reduces exposure but does not remove the flaw, since the missing check cannot be fixed by perimeter controls alone. Consult the GitHub Security Advisory GHSA-9gm5-9rfh-m6vx for the authoritative vendor guidance.
Affected VersionsENISA
Affected Packages
Source: OSV (Open Source Vulnerabilities)
Affects your stack
Affects 2 packages in go, euvd
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
CoreDNS is a Go-based, plugin-driven DNS server that ships multiple listener transports, and this flaw is a request-parsing policy gap between them. The miekg/dns library provides dns.DefaultMsgAcceptFunc, a header-level admission policy that rejects messages with the QR response bit set, rejects opcodes other than QUERY and NOTIFY (which is precisely what rules out RFC 2136 UPDATE, opcode 5), and rejects messages with more than one question or oversized answer/authority/additional section counts. The UDP, TCP, and DNS-over-TLS listeners apply this policy before unpacking; the DoH, DoH3, DoQ, and gRPC listeners instead called dns.Msg.Unpack directly in plugin/pkg/doh/doh.go, core/dnsserver/server_quic.go, and core/dnsserver/server_grpc.go, so a crafted UPDATE was unpacked and handed to the plugin chain unchanged. This is CWE-441 (Unintended Proxy or Intermediary / confused deputy): CoreDNS does not author the zone change, it merely relays the attacker's UPDATE to an upstream that trusts the CoreDNS source address or connection, and the change is then attributed to CoreDNS. The upstream fix commit 530b0a5ff2ad68cc0421f10dd93568945cc671c9 introduces plugin/pkg/dnsutil/message.go with an UnpackRequest helper that decodes the header and applies dns.DefaultMsgAcceptFunc before un-marshalling the full message, and wires it into all four listeners; the same commit also adds http.MaxBytesReader(nil, req.Body, maxDNSQuerySize) to the DoH body path, tightening request-size handling as well. Note that the supplied tag set labels this 'Information Disclosure', which does not match the actual integrity-focused impact described by the advisory and the fix.
Know when Coredns gets its next vulnerability
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
Severity by source
AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N
Unauthenticated network reach via alt DNS transports, but success depends on upstream trusting CoreDNS and lacking TSIG (AC:H); confused deputy crosses to the upstream zone authority (S:C), high integrity impact, limited availability.
Primary rating from Vendor (GitHub_M).
CVSS VectorVendor: GitHub_M
Lifecycle Timeline
2DescriptionCVE.org
CoreDNS is a DNS server written in Go. Prior to 1.14.7, the DNS-over-HTTPS, DNS-over-HTTP/3, DNS-over-QUIC, and DNS-over-gRPC listeners in plugin/pkg/doh/doh.go, core/dnsserver/server_quic.go, and core/dnsserver/server_grpc.go call dns.Msg.Unpack without the dns.DefaultMsgAcceptFunc request policy used by UDP, TCP, and DNS-over-TLS. An unauthenticated client can send an RFC 2136 UPDATE that the proxy or forward plugin passes unchanged to an update-capable upstream. If that upstream trusts CoreDNS's source address or connection and does not require an attacker-unknown end-to-end TSIG, the request appears to originate from CoreDNS and can add, replace, or delete DNS records, redirect traffic, take over names, alter mail routing, or disrupt the writable zone. This issue is fixed in version 1.14.7.
Technical POC Analysis
CWE-441 (Unintended Proxy or Intermediary / "confused deputy").
Full technical POC analysis - root cause, step-by-step exploitation and patch breakdown - is part of the Pro and Business plans.
Executive ViewAI
CoreDNS versions prior to 1.14.7 contain a DNS UPDATE injection flaw that can let remote clients smuggle RFC 2136 dynamic updates through encrypted and gRPC listeners into upstream nameservers when CoreDNS uses the proxy or forward plugin against an update-capable upstream that trusts CoreDNS and lacks end-to-end TSIG. Successful exploitation could allow attackers to add, replace, or delete DNS records, hijack names, or alter mail routing in writable zones, impacting organizations that rely on CoreDNS for DNS resolution and forwarding. No public exploit identified at time of analysis, but the configuration prerequisites mean only certain deployments are at immediate risk.
No vendor-released patch identified at time of analysis. Interim mitigations include disabling or restricting access to DoH, DoH3, DoQ, and DoGRPC listeners; enforcing TSIG or IP allowlisting on upstream dynamic-update endpoints; ensuring upstream servers do not trust CoreDNS source addresses for RFC 2136 updates; and monitoring for unauthorized UPDATE opcode traffic.
Threat Intelligence Overview
NVD
CVE.org
EPSS
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
What every action level means
SSVC AssessmentENISA
Priority Score
Memory-exhaustion denial of service in CoreDNS prior to 1.14.7 lets a remote unauthenticated attacker terminate the serv
Coredns versions up to 1.14.2 contains a vulnerability that allows attackers to crash the DNS server by sending speciall
CoreDNS versions prior to 1.14.2 allow authenticated attackers to bypass DNS access controls through a Time-of-Check Tim
Remote denial of service in CoreDNS versions prior to 1.14.4 allows an unauthenticated attacker to crash the DNS server
A denial of service vulnerability in versions (CVSS 7.5). High severity vulnerability requiring prompt remediation. Vend
CoreDNS is a DNS server that chains plugins. Prior to version 1.14.0, multiple CoreDNS server implementations (gRPC, HTT
Nil pointer dereference in CoreDNS prior to 1.14.5 allows remote unauthenticated attackers to crash or degrade the DNS s
Unhandled Go runtime panic in CoreDNS 1.9.4 through 1.14.4 allows a network-reachable DNS client with AXFR permission to
Exploit-DB