CVE-2026-33489

What it actually does

CoreDNS versions prior to 1.14.3 can apply the wrong zone-transfer access control rule when both a parent zone and a more-specific subzone are configured in the transfer plugin. The vulnerable longestMatch() logic compares zone names lexicographically instead of selecting the true longest matching DNS suffix. In affected configurations, a permissive parent-zone AXFR/IXFR rule can override a restrictive subzone rule, allowing an unauthenticated remote client to retrieve the full contents of the subzone. The impact is unauthorized disclosure of DNS zone data; it does not directly permit record modification or service disruption.

Why it matters to the business

An attacker who can reach the affected CoreDNS service may be able to download complete DNS zone data that was intended to be restricted, exposing hostnames, service locations, internal naming patterns, mail and infrastructure records, and other reconnaissance data useful for phishing, targeting, and follow-on attacks. The issue is not currently listed in CISA KEV, has low EPSS activity, and has no reported public exploit maturity, but externally reachable authoritative DNS servers or zones containing sensitive infrastructure information should still be prioritized because exploitation is simple once the configuration pattern exists.

How an attack unfolds

An attacker first identifies a CoreDNS server authoritative for a target domain and checks whether zone transfers are accepted over TCP/53. If the server is running a vulnerable version and its Corefile defines both a parent zone and a more-specific subzone with different transfer ACLs, the attacker requests AXFR or IXFR for the restricted subzone. Due to the flawed lexicographic ACL selection, CoreDNS may evaluate the permissive parent-zone transfer stanza instead of the restrictive subzone stanza. The server then returns the subzone’s complete DNS contents to a client that should have been denied. The attacker can use the retrieved records to map infrastructure, identify administrative interfaces, enumerate service names, discover mail and cloud assets, and support later intrusion attempts.

How to fix it

Upgrade CoreDNS to version 1.14.3 or later, which corrects the zone matching logic in the transfer plugin. If immediate upgrade is not possible, reduce exposure by disabling the transfer plugin where zone transfers are not required, restricting TCP/53 zone-transfer access at firewalls to authorized secondary DNS servers only, and ensuring parent and subzone transfer ACLs are not configured such that a permissive parent rule could apply to a sensitive subzone. Review CoreDNS Corefile configurations for overlapping parent and subzone transfer stanzas and apply the most restrictive appropriate rules consistently. After upgrading or changing configuration, restart or roll CoreDNS instances so the fixed binary and updated configuration are active.

How to confirm the fix worked

Confirm that all running CoreDNS instances report version 1.14.3 or later. Review Corefile configurations for the transfer plugin and identify overlapping parent and subzone definitions with different ACLs. From an unauthorized source address, attempt AXFR and IXFR requests against restricted subzones using standard DNS tools such as dig; the expected result is refusal, denial, timeout, or no transfer, not a complete zone response. From authorized secondary DNS systems, verify that legitimate transfers still succeed. Where DNS query logging or network inspection is available, confirm that unsolicited AXFR/IXFR requests from non-approved sources are blocked or denied.

Typical attack path

1. Discover authoritative CoreDNS servers for a target zone using NS lookups and DNS reconnaissance.
2. Probe TCP/53 to determine whether DNS zone-transfer requests are reachable.
3. Submit AXFR or IXFR requests for candidate subzones, especially more-specific zones beneath a parent domain.
4. Rely on the vulnerable ACL-selection behavior to have a permissive parent-zone rule override the intended restrictive subzone rule.
5. Collect the returned zone contents, including hostnames, service records, mail records, and infrastructure metadata.
6. Use the exposed DNS data for targeted reconnaissance, phishing, vulnerability scanning, or follow-on intrusion planning.

How to detect it

Look for evidence of unauthorized DNS zone-transfer activity. Primary sources include CoreDNS query logs, DNS server logs, packet captures, firewall logs, IDS/NSM telemetry, and load balancer or flow logs for TCP/53. Search for AXFR and IXFR requests targeting subzones, especially from source IPs that are not approved secondary DNS servers. Successful exploitation may appear as large TCP/53 responses, multi-message DNS transfer sessions, or query logs showing AXFR/IXFR returning NOERROR rather than REFUSED, NOTAUTH, or denied. Review historical logs since deployment of affected versions or since the vulnerable overlapping parent/subzone transfer configuration was introduced. If threat hunting finds a successful unauthorized transfer, assume the zone contents were disclosed and investigate subsequent scanning, phishing, or access attempts using hostnames exposed in the transferred zone.

• AXFR IN
• IXFR IN
• "AXFR IN
• "IXFR IN
• QTYPE=AXFR
• QTYPE=IXFR
• DNS QTYPE=AXFR
• DNS QTYPE=IXFR
• TCP/53 AXFR
• TCP/53 IXFR
• opcode QUERY qtype AXFR
• opcode QUERY qtype IXFR
• NOERROR qr AXFR
• NOERROR qr IXFR
• REFUSED qr AXFR
• REFUSED qr IXFR
• dig axfr
• dig ixfr

What your security team should do

• Inventory CoreDNS deployments and prioritize externally reachable authoritative DNS servers using the transfer plugin.
• Upgrade CoreDNS to 1.14.3 or later across all affected deployments.
• Audit Corefile transfer plugin configuration for overlapping parent-zone and subzone ACLs, especially where parent zones are more permissive than subzones.
• Restrict DNS zone transfers at the network layer so TCP/53 AXFR and IXFR are only allowed from approved secondary DNS servers or transfer partners.
• Enable or review DNS query logging for AXFR and IXFR requests and alert on transfer attempts from unapproved source addresses.
• Inspect historical DNS logs and network telemetry for successful or repeated AXFR/IXFR requests against sensitive subzones.
• Treat any unauthorized successful zone transfer as an information disclosure incident and assess exposed records for follow-on risk.