CVE-2026-86003 Overview
CoreDNS is a DNS server written in Go that is widely deployed as the default DNS provider in Kubernetes clusters. CVE-2026-86003 affects the DNS-over-HTTPS (DoH), DNS-over-HTTP/3, DNS-over-QUIC, and DNS-over-gRPC listeners prior to version 1.14.7. These listeners call dns.Msg.Unpack without applying the dns.DefaultMsgAcceptFunc request policy used by the UDP, TCP, and DNS-over-TLS paths. An unauthenticated network client can submit an RFC 2136 UPDATE message that CoreDNS forwards to an upstream server. If the upstream trusts the CoreDNS source address, the update executes with CoreDNS's identity. This issue is fixed in CoreDNS 1.14.7 [CWE-441].
Critical Impact
Unauthenticated attackers can inject DNS UPDATE messages that update-capable upstreams accept as originating from CoreDNS, allowing record modification, traffic redirection, name takeover, and mail routing tampering.
Affected Products
- CoreDNS versions prior to 1.14.7
- Deployments exposing DNS-over-HTTPS or DNS-over-HTTP/3 listeners
- Deployments exposing DNS-over-QUIC or DNS-over-gRPC listeners
Discovery Timeline
- 2026-09-16 - CVE-2026-86003 published to NVD
- 2026-09-16 - Last updated in NVD database
Technical Details for CVE-2026-86003
Vulnerability Analysis
CoreDNS accepts DNS messages across multiple transports. For UDP, TCP, and DNS-over-TLS, incoming messages pass through dns.DefaultMsgAcceptFunc, which enforces the request policy defined by the miekg/dns library. This policy rejects messages that are not standard queries, including RFC 2136 dynamic UPDATE messages.
The alternate transports handled in plugin/pkg/doh/doh.go, core/dnsserver/server_quic.go, and core/dnsserver/server_grpc.go skip this check. They invoke dns.Msg.Unpack directly and hand the resulting message to the plugin chain. Consequently, an UPDATE message reaches the proxy or forward plugin unchanged.
When CoreDNS forwards the UPDATE to an upstream that trusts CoreDNS's source address or connection, and does not enforce end-to-end TSIG authentication, the upstream applies the update. The attacker can add, replace, or delete records in a writable zone. Downstream effects include traffic redirection, domain takeover, mail routing tampering (MX record manipulation), and zone disruption.
Root Cause
The root cause is an inconsistent request policy across transports [CWE-441: Unintended Proxy or Intermediary]. The DoH, DoH/3, DoQ, and DoG listeners omit the acceptance function that filters non-query opcodes on other transports, allowing OpCode 5 (UPDATE) messages to bypass the input filter.
Attack Vector
An unauthenticated attacker crafts an RFC 2136 UPDATE message and delivers it to any exposed DoH, DoH/3, DoQ, or DoG endpoint. CoreDNS unpacks and forwards the message. The upstream authoritative server, trusting CoreDNS by IP or transport, applies the update. No credentials, user interaction, or prior access to the upstream are required from the attacker.
// Patch reference: core/dnsserver/server_grpc.go
"github.com/coredns/caddy"
"github.com/coredns/coredns/pb"
+ "github.com/coredns/coredns/plugin/pkg/dnsutil"
"github.com/coredns/coredns/plugin/pkg/reuseport"
"github.com/coredns/coredns/plugin/pkg/transport"
// Patch reference: core/dnsserver/server_quic.go
"time"
"github.com/coredns/coredns/plugin/metrics/vars"
+ "github.com/coredns/coredns/plugin/pkg/dnsutil"
clog "github.com/coredns/coredns/plugin/pkg/log"
// Source: https://github.com/coredns/coredns/commit/530b0a5ff2ad68cc0421f10dd93568945cc671c9
The patch introduces the plugin/pkg/dnsutil package into the QUIC and gRPC server initialization paths, aligning message acceptance policy with the UDP, TCP, and TLS transports.
Detection Methods for CVE-2026-86003
Indicators of Compromise
- DNS messages with OpCode 5 (UPDATE) received on DoH, DoH/3, DoQ, or DoG listener ports.
- Unexpected record changes (A, AAAA, MX, NS, CNAME) in authoritative zones downstream of CoreDNS.
- Zone transfer diffs showing records added, replaced, or removed outside change-management windows.
- CoreDNS access logs showing forwarded UPDATE messages to update-capable upstreams.
Detection Strategies
- Inspect CoreDNS query logs and correlate opcodes against transport type; UPDATE on DoH/DoQ/DoG is anomalous.
- Deploy authoritative-server audit logging for dynamic update events and alert on updates lacking TSIG signatures.
- Compare zone snapshots at scheduled intervals and alert on unauthorized deltas.
Monitoring Recommendations
- Monitor CoreDNS versions across clusters and flag any instance below 1.14.7.
- Track ingress traffic to DoH, DoH/3, DoQ, and DoG endpoints and baseline expected message opcodes.
- Alert on authoritative upstreams accepting UPDATE messages from CoreDNS source IPs.
How to Mitigate CVE-2026-86003
Immediate Actions Required
- Upgrade all CoreDNS instances to version 1.14.7 or later.
- Audit upstream authoritative servers reachable via the forward or proxy plugin and require TSIG for dynamic updates.
- Restrict exposure of DoH, DoH/3, DoQ, and DoG listeners to trusted networks where feasible.
- Review recent zone changes on writable upstreams for unauthorized modifications.
Patch Information
The fix is available in CoreDNS 1.14.7. See the GitHub Security Advisory GHSA-9gm5-9rfh-m6vx, the GitHub Release v1.14.7, and the remediation commit 530b0a5.
Workarounds
- Disable the DoH, DoH/3, DoQ, and DoG listeners until upgrading to 1.14.7.
- Configure upstream authoritative servers to reject UPDATE messages without a valid end-to-end TSIG signature.
- Enforce network policies that limit which clients can reach CoreDNS alternate-transport listeners.
# Verify installed CoreDNS version and upgrade
coredns -version
# Kubernetes: update the CoreDNS image tag to 1.14.7
kubectl -n kube-system set image deployment/coredns \
coredns=registry.k8s.io/coredns/coredns:v1.14.7
# Confirm rollout
kubectl -n kube-system rollout status deployment/coredns
Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.

