CVE-2026-33489: CoreDNS Information Disclosure Flaw

CVE-2026-33489 Overview

CVE-2026-33489 is an authorization bypass vulnerability in the CoreDNS transfer plugin. CoreDNS is a Go-based DNS server that chains plugins to provide name resolution services. In versions prior to 1.14.3, the plugin selects the wrong Access Control List (ACL) stanza when both a parent zone and a more-specific subzone are configured. The longestMatch() function in plugin/transfer/transfer.go performs a lexicographic string comparison instead of an actual longest-suffix match. As a result, a permissive parent-zone transfer rule can override a restrictive subzone rule. An unauthorized remote client can perform AXFR or IXFR queries against the subzone and retrieve its full contents.

Critical Impact
Remote attackers without authentication can exfiltrate complete DNS zone data for protected subzones, exposing internal hostnames, infrastructure layout, and sensitive records.

Affected Products

CoreDNS versions prior to 1.14.3
Deployments using the transfer plugin with parent and subzone ACL configurations
Kubernetes clusters and cloud-native environments running vulnerable CoreDNS images

Discovery Timeline

2026-05-05 - CVE-2026-33489 published to NVD
2026-05-07 - Last updated in NVD database

Technical Details for CVE-2026-33489

Vulnerability Analysis

The flaw resides in how the transfer plugin resolves which ACL stanza applies to an incoming AXFR or IXFR request. Operators can configure separate transfer policies for a parent zone (for example, example.org.) and a more-specific subzone (for example, a.example.org.). The expected behavior is that requests for the subzone match the more-specific rule. The plugin instead compares zone names as strings using lexicographic ordering. Because "example.org." sorts after "a.example.org.", the parent rule wins and its permissive ACL applies to the subzone. This violates the principle that the longest-suffix match should take precedence in DNS authorization decisions [CWE-863].

Root Cause

The longestMatch() helper in plugin/transfer/transfer.go does not measure the suffix length of the matched zone. It instead returns the lexicographically greater zone name among candidates. Lexicographic comparison ignores DNS label hierarchy, so a parent zone string can outrank its subzone string depending on character ordering. The result is incorrect ACL selection during transfer authorization.

Attack Vector

A remote attacker sends an AXFR or IXFR query for a protected subzone to a vulnerable CoreDNS instance. The server applies the parent zone's permissive transfer ACL rather than the subzone's restrictive one. The server responds with the full zone transfer, exposing every record in the subzone. No authentication, credentials, or user interaction are required. Exploitation requires only network reachability to the CoreDNS listener and knowledge of an affected zone name.

The vulnerability mechanism is described in the GitHub Security Advisory GHSA-h8mm-c463-wjq3. No proof-of-concept exploit has been published, and the EPSS probability is 0.041%.

Detection Methods for CVE-2026-33489

Indicators of Compromise

Unexpected AXFR or IXFR query responses originating from CoreDNS to external or unauthorized client IP addresses
Outbound DNS responses with abnormally large payloads to clients that should not receive zone transfers
CoreDNS query logs showing transfer requests for subzones from sources outside the configured ACL

Detection Strategies

Audit running CoreDNS versions across the fleet and flag any instance below 1.14.3 that loads the transfer plugin
Inspect Corefile configurations for overlapping transfer stanzas where a parent zone and subzone share the same server block
Replay synthetic AXFR queries from unauthorized source addresses against test environments to confirm whether subzone ACLs are honored

Monitoring Recommendations

Enable the CoreDNS log plugin and forward query logs to a centralized SIEM for correlation on transfer query types
Alert on AXFR or IXFR requests from source addresses not present in the configured to allowlist
Monitor CoreDNS metrics for spikes in transfer request counts and response sizes

How to Mitigate CVE-2026-33489

Immediate Actions Required

Upgrade all CoreDNS deployments to version 1.14.3 or later, which replaces lexicographic comparison with a proper longest-suffix match
Inventory every Kubernetes cluster, sidecar, and container image that bundles CoreDNS and schedule patching
Restrict network access to the DNS transfer port at the firewall or network policy layer until patching completes

Patch Information

The issue is fixed in CoreDNS Release v1.14.3. Operators running official CoreDNS container images should pull the updated tag and roll deployments. Kubernetes administrators should update the CoreDNS image referenced by the coredns Deployment in the kube-system namespace and verify the rollout status.

Workarounds

Remove overlapping parent-zone transfer stanzas and define ACLs only at the most-specific zone level until the patch is applied
Disable the transfer plugin entirely on instances that do not require AXFR or IXFR support
Enforce TSIG-authenticated transfers or restrict transfer traffic to trusted secondary servers using network ACLs

bash

# Configuration example - explicit per-subzone transfer block
a.example.org. {
    transfer {
        to 192.0.2.10
    }
    file /etc/coredns/a.example.org.zone
}

example.org. {
    transfer {
        to 192.0.2.20
    }
    file /etc/coredns/example.org.zone
}