AI analysis
In ISC BIND 9, a secondary server that restricts zone transfers with TSIG may begin serving data from an incoming multi-message TCP IXFR before the final message carrying the TSIG signature arrives, and it never rolls back to the pre-transfer state if that signature never arrives (CWE-349, acceptance of extraneous untrusted data). An attacker who does not possess a valid TSIG key but can impersonate the zone's primary on the transfer path (e.g., via a spoofed or man-in-the-middle transfer session) can send unauthorized zone contents, which the secondary then serves to clients. The impact is loss of DNS data integrity with limited availability impact and no confidentiality impact (CVSS 6.5, network vector with high attack complexity). Any BIND 9 deployment in the affected version ranges configured as a secondary zone with TSIG-restricted transfers is affected, and the transfer must be a multi-message TCP IXFR as described by RFC 8945. No exploitation in the wild, public proof-of-concept, or CISA KEV listing is known; ISC disclosed this flaw as one of fourteen BIND 9 vulnerabilities.
What to do: Upgrade BIND 9 to the fixed releases from ISC's advisory, i.e., versions later than 9.18.50, 9.20.27, or 9.21.25 (or the matching -S1 builds) depending on the branch in use. As interim mitigations on secondaries, disable incremental transfers to primaries (request-ixfr no; in named.conf, since the flaw requires a multi-message TCP IXFR) and layer source-address restrictions (allow-notify / primaries ACLs) on top of TSIG so only the genuine primary can initiate updates. Audit named.conf for secondary zones whose transfer protection relies solely on TSIG keys.
Affected
| ISC BIND 9 | 9.11.0 through 9.18.50 |
| ISC BIND 9 | 9.20.0 through 9.20.27 |
| ISC BIND 9 | 9.21.0 through 9.21.25 |
| ISC BIND 9 -S1 (support preview) editions | 9.11.3-S1 through 9.18.50-S1 |
| ISC BIND 9 -S1 (support preview) editions | 9.20.9-S1 through 9.20.27-S1 |
Estimated exposure
mass1,000,000+ BIND 9 installations, with roughly 100,000+ plausibly matching the vulnerable secondary-with-TSIG configuration (public scans show on the order of a… — BIND is the most widely deployed DNS server software and internet-wide scans (Shodan/Censys) historically show on the order of a million exposed BIND instances; TSIG-secured transfers between primaries and secondaries are a standard…
Order-of-magnitude estimate by the model from install counts, market share and public scan data it knows; verify before quoting.
Description
For a secondary zone with transfers restricted by TSIG, `named` may start to serve the data provided in a zone transfer before the final message with the TSIG signature arrives. This could allow an attacker that does not actually possess a valid TSIG signature to send unauthorized zone contents to a secondary server. Although no TSIG signature ever arrives, `named` does not rollback to the pre-transfer state. To exploit the vulnerability, the transfer must be a multi-message TCP IXFR, as described by RFC 8945. This issue affects BIND 9 versions 9.11.0 through 9.18.50, 9.20.0 through 9.20.27, 9.21.0 through 9.21.25, 9.11.3-S1 through 9.18.50-S1, and 9.20.9-S1 through 9.20.27-S1.