CVE-2026-86003
Description
A flaw was found in CoreDNS. The DNS-over-HTTPS, DNS-over-HTTP/3, DNS-over-QUIC, and DNS-over-gRPC listeners do not properly validate incoming DNS update requests. An unauthenticated client can send a specially crafted DNS update (RFC 2136 UPDATE) that CoreDNS forwards to an upstream DNS server. If the upstream server trusts CoreDNS, this can lead to unauthorized modification, addition, or deletion of DNS records, potentially redirecting traffic or disrupting the DNS zone.
Statement
A confused deputy vulnerability was found in CoreDNS, a DNS server written in Go. Prior to version 1.14.7, the DNS-over-HTTPS, DNS-over-HTTP/3, DNS-over-QUIC, and DNS-over-gRPC request paths do not apply the dns.DefaultMsgAcceptFunc request policy used by the UDP, TCP, and DNS-over-TLS paths. An unauthenticated remote attacker can submit an RFC 2136 DNS UPDATE message over custom transports that CoreDNS forwards to an upstream authoritative DNS server. If the upstream server trusts CoreDNS's source address or connection and does not require an end-to-end TSIG signature, the UPDATE request executes with CoreDNS's identity, allowing the attacker to add, replace, or delete DNS records in writable zones. This can enable traffic redirection, subdomain takeover, email interception through MX record modification, and other integrity attacks against DNS-based services. This issue affects Red Hat OpenShift Container Platform and Red Hat Advanced Cluster Management components that use vulnerable versions of CoreDNS. The issue is fixed in CoreDNS 1.14.7.
Mitigation
Until updates are available, administrators can implement the following mitigations to prevent DNS UPDATE proxying attacks:
1. If DNS-over-HTTPS, DNS-over-HTTP/3, DNS-over-QUIC, or DNS-over-gRPC are not required, disable these custom transport protocols. Standard UDP and TCP DNS listeners are not affected by this vulnerability.
2. Configure upstream authoritative DNS servers to reject UPDATE messages that lack a valid end-to-end TSIG (Transaction Signature) cryptographic signature, regardless of source IP address trust.
3. Review upstream DNS server ACLs to ensure CoreDNS does not have unnecessary write permissions to authoritative zones. Apply principle of least privilege.
4. If CoreDNS must forward to authoritative servers, implement network segmentation and firewall rules to restrict which DNS UPDATE operations can reach upstream servers.
5. Monitor DNS zone change logs on authoritative servers for unexpected UPDATE operations originating from CoreDNS IP addresses.
Apply updates as they become available from Red Hat product teams. For OpenShift clusters, prioritize patching environments that forward DNS queries to internal authoritative DNS servers with UPDATE support enabled.
Common Vulnerability Scoring System (CVSS) Score Details
Info alert:Important note
CVSS scores for open source components depend on vendor-specific factors (e.g. version or build chain). Therefore, Red Hat's score and impact rating can be different from NVD and other vendors. Red Hat remains the authoritative CVE Naming Authority (CNA) source for its products and services (see Red Hat classifications).
The following CVSS metrics and score provided are preliminary and subject to review.
CVSS v3 Score Breakdown
| Red Hat | NVD | cve.org | |
|---|---|---|---|
| Base Score | 7.5 | N/A | 7.5 |
| Attack Vector | Network | N/A | Network |
| Attack Complexity | Low | N/A | Low |
| Privileges Required | None | N/A | None |
| User Interaction | None | N/A | None |
| Scope | Unchanged | N/A | Unchanged |
| Confidentiality | None | N/A | None |
| Integrity Impact | High | N/A | High |
| Availability Impact | None | N/A | None |
Vector
Red Hat: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N
cve.org: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N
Frequently Asked Questions
Not sure what something means? Check out our Security Glossary.
Want to get errata notifications? Sign up here.
