Severity by source
CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X
AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N
Primary rating from GitHub Advisory.
CVSS VectorGitHub Advisory
CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X
Lifecycle Timeline
3DescriptionGitHub Advisory
Summary
CoreDNS' transfer plugin can select the wrong ACL stanza when both a parent zone and a more-specific subzone are configured. A permissive parent-zone transfer rule can override a restrictive subzone rule (name-dependent), allowing an unauthorized client to perform AXFR/IXFR for the subzone and retrieve its zone contents.
Details
In plugin/transfer/transfer.go, stanza selection is implemented by longestMatch(), which is documented as "longest zone match wins", but it actually chooses the winner via a lexicographic string comparison:
- zone := "" // longest zone match wins (plugin/transfer/transfer.go)
- if z > zone { zone = z; x = xfr } (plugin/transfer/transfer.go)
So, a parent zone like example.org. can beat a child zone like a.example.org. purely due to lexicographic ordering ("example.org." > "a.example.org."), even though the child zone is the longer/more specific suffix match. The bypass is data-dependent (some child labels will win, some will lose), making it operationally non-intuitive.
PoC
- Adjust COREDNS_BIN in the PoC to point at right path (see the top-level const definitions for tunables as well)
- Run python3 ./acl-repro.py
- Expected output:
* Baseline (only subzone transfer rule) * axfr a.example.org.: rcode=5 ancount=0 (expected REFUSED=5)
* Candidate (add permissive parent transfer rule) * axfr a.example.org.: rcode=0 ancount=5 (expected NOERROR=0 with ancount>0)
* OK * Subzone transfer ACL bypass reproduced: adding a permissive parent-zone stanza can override a stricter child-zone stanza due to lexicographic zone selection.
Impact
Unauthorized zone transfer can expose full zone contents to a remote network client that was intended to be denied by a subzone-specific transfer policy.
Analysis
Summary
CoreDNS' transfer plugin can select the wrong ACL stanza when both a parent zone and a more-specific subzone are configured. A permissive parent-zone transfer rule can override a restrictive subzone rule (name-dependent), allowing an unauthorized client to perform AXFR/IXFR for the subzone and retrieve its zone contents.
Details
In plugin/transfer/transfer.go, stanza selection is implemented by longestMatch(), which is documented as "longest zone match wins", but it actually chooses the winner via a lexicographic string comparison:
- zone := "" // longest zone match wins (plugin/transfer/transfer.go)
- if z > zone { zone = z; x = xfr } (plugin/transfer/transfer.go)
So, a parent zone like example.org. can beat a child zone like a.example.org. purely due to lexicographic ordering ("example.org." > "a.example.org."), even though the child zone is the longer/more specific suffix match. The bypass is data-dependent (some child labels will win, some will lose), making it operationally non-intuitive.
PoC
- Adjust COREDNS_BIN in the PoC to point at right path (see the top-level const definitions for tunables as well)
- Run python3 ./acl-repro.py
- Expected output:
* Baseline (only subzone transfer rule) * axfr a.example.org.: rcode=5 ancount=0 (expected REFUSED=5)
* Candidate (add permissive parent transfer rule) * axfr a.example.org.: rcode=0 ancount=5 (expected NOERROR=0 with ancount>0)
* OK * Subzone transfer ACL bypass reproduced: adding a permissive parent-zone stanza can override a stricter child-zone stanza due to lexicographic zone selection.
Impact
Unauthorized zone transfer can expose full zone contents to a remote network client that was intended to be denied by a subzone-specific transfer policy.
Same weakness CWE-862 – Missing Authorization
View allSame technique Authentication Bypass
View allVendor StatusVendor
SUSE
Severity: High| Product | Status |
|---|---|
| openSUSE Leap 16.0 | Fixed |
Share
External POC / Exploit Code
Leaving vuln.today
EUVD-2026-27450
GHSA-h8mm-c463-wjq3