BIND 9.20.29 and 9.21.26 Fix 14 Security Flaws, Including DNS-over-HTTPS Crash

ISC has released BIND 9.20.29 and 9.21.26 after disclosing fourteen security vulnerabilities in BIND 9. The issues range from remotely triggerable crashes and resource exhaustion to DNSSEC validation problems and unauthorized zone data being served by secondary servers.[1]

The update matters because BIND is commonly deployed in both authoritative DNS and recursive-resolver roles. The September disclosure does not describe a single vulnerability with one common attack path. Instead, it covers fourteen separate defects with different prerequisites and different effects.[1][2]

The most immediately notable issue is CVE-2026-77692, a flaw affecting BIND servers that answer DNS-over-HTTPS (DoH) requests. According to the reported ISC advisory details, an unauthenticated sender can crash named using a specially formed request containing an invalid SIG(0) signature if the connection is closed before signature processing finishes.[3]

What ISC Fixed in BIND 9

ISC disclosed the fourteen vulnerabilities on September 16, 2026. The official disclosure lists CVEs ranging from CVE-2026-19033 through CVE-2026-81736, covering problems in zone transfers, DNSSEC validation, resolver caching, SVCB/HTTPS processing, TKEY handling and DNS-over-HTTPS.[1]

The current stable BIND branch is 9.20, and ISC released 9.20.29 with fixes for all fourteen vulnerabilities. BIND 9.21.26, which is the development branch, fixes thirteen because CVE-2026-19662 does not affect that branch. The Supported Preview Edition is addressed by 9.20.29-S1.[2][3]

The BIND 9.20.29 release notes[2] document the security update, while ISC's vulnerability information provides the affected-version and advisory details for the individual CVEs.[1]

The Fourteen Vulnerabilities

The fourteen flaws are not equivalent. Seven carry ISC's High rating at CVSS 3.1 score 7.5, while the remaining seven are rated Medium, with scores ranging from 5.3 to 6.5.[3]

The vulnerability list, effects, affected ranges and ISC scores above are based on the September 2026 reporting of ISC's individual advisories and the ISC disclosure.[1][3]

CVE-2026-77692: The DNS-over-HTTPS Crash

The flaw drawing particular attention is CVE-2026-77692. It affects BIND servers that provide DNS-over-HTTPS and is rated CVSS 3.1: 7.5 (High) by ISC.[3]

The important point is the attack requirement. The issue does not require the sender to authenticate. A malicious client can send a request containing an invalid SIG(0) signature and close the connection before named finishes processing that signature. Under the conditions described by ISC, the server process can crash.[3]

This is a denial-of-service condition, not evidence of remote code execution. The available reporting does not establish that the flaw provides arbitrary code execution, privilege escalation or persistence. Calling it an RCE would therefore go beyond the evidence.[3]

The September 17 vulnerability report[3] also identifies CVE-2026-77692 as one of two vulnerabilities in this group that can be triggered by a request without requiring the attacker to operate their own DNS server.

Several Other Bugs Can Crash Recursive Resolvers

The other crash-related vulnerabilities have different prerequisites.

CVE-2026-19667 can crash a recursive resolver after it receives a specially crafted negative DNS response of exactly 65,536 bytes from an attacker-controlled server. The reported affected range includes BIND 9.11 through 9.18.50 as well as the 9.20 and 9.21 branches.[3]

CVE-2026-19666 involves BIND's DNS64 processing when break-dnssec yes is configured. A malformed answer served from cache can trigger the failure condition.[3]

CVE-2026-80274 affects validating resolvers handling a particular combination of NSEC and NSEC3 records in a wildcard response. Depending on the circumstances, the result can include a resolver crash, SERVFAIL or an incorrect denial response.[3]

CVE-2026-19662 is somewhat different. It requires a signed attacker-controlled zone and a particular ordering and timing of DNS responses. It affects the 9.11–9.18 and 9.20 branches but does not affect BIND 9.21.[3]

Not Every Problem Ends With a Crash

Four vulnerabilities are primarily about resource consumption rather than immediate process termination.

CVE-2026-81563 can cause resolver cache growth beyond its intended limit when SVCB/HTTPS alias processing repeatedly encounters more than thirteen target records. CVE-2026-81736 can drive CPU exhaustion through cached SVCB/HTTPS alias trees under the conditions described by ISC.[3]

There are also two DNSSEC-related resource issues. CVE-2026-19668 can cause excessive CPU work during DNSSEC validation when a zone contains many key tags without a valid match. ISC rates it CVSS 3.1 5.3 Medium and notes that default record limits reduce exposure.[3]

CVE-2026-75029 concerns repeated identical singleton records such as SOA, CNAME or DNAME records. The issue can result in memory consumption beyond configured limits.[3]

These issues illustrate why simply looking for "server crash" in a vulnerability summary isn't enough. Resource exhaustion can also affect DNS availability, especially on infrastructure handling a large volume of recursive queries.

DNSSEC Integrity Issues

Two of the fourteen vulnerabilities affect how validating resolvers interpret DNSSEC evidence.

CVE-2026-19941 involves an out-of-zone NSEC record being accepted as proof that a wildcard does not exist. ISC rates the vulnerability CVSS 3.1: 5.9 (Medium). Its advisory says an attacker at the same or an upstream zone level could potentially cause a resolver to accept a forged denial of existence, resulting in cache poisoning.[4]

The official ISC advisory for CVE-2026-19941[4] says the vulnerability is remotely exploitable and affects BIND 9.11.0 through 9.18.50, 9.20.0 through 9.20.27 and 9.21.0 through 9.21.25.

CVE-2026-77119 has a related DNSSEC theme. In this case, a validly signed NSEC3 record from an unrelated sibling zone can be accepted as an insecurity proof. ISC describes the resulting condition as potentially allowing false delegations and cache poisoning.[5]

The ISC advisory for CVE-2026-77119[5] rates the issue CVSS 3.1 5.9 Medium and says no active exploits are known to ISC.

Zone Transfer and Authoritative DNS Issues

CVE-2026-19033 concerns incremental zone transfers, or IXFR. The vulnerability can allow a secondary server to begin serving transferred data before the final TSIG-authenticated message has arrived. The result can be unauthorized zone contents being served if an attacker can deliver the relevant transfer data.[3]

The fix changes the handling so that a TSIG is required on every message of an incoming zone transfer. The BIND 9.20.29 changelog says modern name servers already sign every message, so ISC does not expect a practical configuration change from this particular fix.[6]

CVE-2026-78301 is different again. It requires an attacker to get a malformed zone loaded onto an authoritative server, for example through a zone transfer. Under the described conditions, an NS or DNAME node above the zone origin can be treated as a zone cut. If the server also provides recursion, the resulting delegation behavior can have additional cache effects.[3]

What About BIND 9.18?

This is an important operational detail.

ISC ended maintenance for the BIND 9.18 branch at the end of June 2026. ISC's current version information lists 9.18.50 as EOL, while BIND 9.20.29 is the current stable release.[7]

Twelve of the fourteen September vulnerabilities affect the 9.18 branch through 9.18.50, and ISC lists no 9.18 release containing the September fixes.[3]

ISC had already announced that 9.18 maintenance would end as scheduled and advised users to prepare for the move to BIND 9.20.[8] Its vulnerability matrix also warns that EOL versions should be assumed vulnerable to new CVEs.[9]

That makes version inventory particularly important. An organization may have patched BIND repeatedly over the years and still be exposed because the installed branch itself is now outside ISC's maintenance window.

Are These Vulnerabilities Being Exploited?

There is currently an important distinction between publicly documented trigger conditions and active exploitation.

ISC's advisories state that it is not aware of active exploits for the fourteen vulnerabilities. The September reporting also notes that reproduction tests are available for several of the flaws, but those tests are intended to verify the vulnerabilities and fixes rather than serve as evidence of exploitation in the wild.[3]

That means these vulnerabilities should not be described as actively exploited simply because technical reproduction material exists. A public test or proof of concept is not equivalent to confirmed exploitation against real-world BIND deployments.

No evidence reviewed for this article establishes remote code execution through these fourteen vulnerabilities either. The documented effects are primarily crashes, resource exhaustion, DNS data-integrity problems and unauthorized zone data handling.[1][3]

What BIND Administrators Should Do

The first step is straightforward: identify every BIND installation and determine which branch it is running.

1. Upgrade supported BIND 9.20 installations to 9.20.29. ISC identifies 9.20.29 as the stable release containing the fourteen fixes.[2]
2. Update BIND 9.21 installations to 9.21.26. That development release contains the applicable fixes for the branch.[1][2]
3. Treat BIND 9.18.50 as EOL. The September fixes are not being backported to the retired branch.[3][7]
4. Check whether DNS-over-HTTPS is enabled. CVE-2026-77692 specifically affects BIND servers answering DoH traffic.[3]
5. Review recursive resolvers separately from authoritative servers. Several of the vulnerabilities require recursive resolution, DNSSEC validation or particular resolver configuration.[3]
6. Check operating-system packages independently. A distribution package version does not necessarily map directly to the upstream BIND release number, so administrators should consult their distribution's security advisory and package status.

Administrators should use the official BIND 9 vulnerability matrix[9] when checking which version fixes a particular CVE. ISC explicitly notes that the matrix identifies the versions containing fixes and distinguishes supported branches from older versions.

One More Release Detail: Why 9.20.29?

The version number is also worth explaining. BIND 9.20.29 follows a withdrawn 9.20.28 release. ISC's release notes state that 9.20.28 was withdrawn after a regression was found during pre-release testing.[2]

So the appearance of 9.20.29 is not evidence that ISC skipped a normal release. The release notes explicitly document the withdrawal and the subsequent security release.[2]

Security Takeaway

The September BIND update is broad rather than centered on one catastrophic vulnerability. Fourteen separate issues were disclosed, and their attack prerequisites vary considerably. Some can affect a server through a single request, while others require a recursive resolver, DNSSEC validation, an attacker-controlled zone or access capable of getting malformed zone data loaded.[1][3]

The most practical takeaway is version management. BIND 9.20.29 is the current stable release containing the September security fixes, while BIND 9.18.50 is EOL.[7] Organizations running BIND should therefore inventory both the software version and the role each server performs: authoritative DNS, recursive resolution, DNSSEC validation, DoH service or a combination of those functions.

There is no verified evidence in the sources reviewed here that these fourteen vulnerabilities are being actively exploited, and the available evidence does not establish RCE. They should nevertheless be handled as security updates because several of the documented conditions can affect DNS availability or the integrity of DNS responses.[3]

Sources & References

1. [1] Internet Systems Consortium / oss-sec — “ISC has disclosed fourteen vulnerabilities in BIND 9” — September 16, 2026 — ISC disclosure archive
2. [2] BIND 9 Documentation — “Release Notes — BIND 9 9.20.29” — September 2026 — BIND 9.20.29 release notes
3. [3] The Hacker News — “BIND 9 Update Fixes 14 Flaws, Including an Unauthenticated Crash Over DNS-over-HTTPS” — September 17, 2026 — Article and vulnerability table
4. [4] Internet Systems Consortium — “CVE-2026-19941: checkwildcard() accepts an out-of-zone NSEC as a wildcard-nonexistence proof” — September 16, 2026 — Official ISC advisory
5. [5] Internet Systems Consortium — “CVE-2026-77119: NSEC3 insecure-referral proof can use unrelated cached NSEC3 RRsets” — September 16, 2026 — Official ISC advisory
6. [6] BIND 9 Documentation — “Changelog — BIND 9 9.20.29” — September 2026 — BIND 9.20.29 changelog
7. [7] Internet Systems Consortium — BIND 9 version status — September 2026 — Current BIND versions
8. [8] Internet Systems Consortium — “Prepare for more frequent BIND security updates” — May 12, 2026 — ISC security-update announcement
9. [9] Internet Systems Consortium — “BIND 9 Software Vulnerability Matrix” — updated August 19, 2026 — BIND 9 vulnerability matrix
10. [10] Wikimedia Commons — “File:BIND 9 logo.jpg” — Vickyrisk, November 29, 2018 — CC BY-SA 4.0 — Image source and license

Image licensing: The hero image is licensed under CC BY-SA 4.0. Attribution is provided in the image caption and source references.[10]