ISC releases BIND 9.20.29 and 9.21.26, patching 14 vulnerabilities
ISC's latest maintenance fixes close 14 vulnerabilities, eight of them rated High severity and several opening the door to cache poisoning.
ISC just dropped two maintenance updates for BIND, the DNS server that quietly resolves names for a large chunk of the Internet. Each exists to close 14 vulnerabilities. That's a heavy haul for a maintenance release.
BIND 9.20.29 lands on the supported stable branch. BIND 9.21.26 rides the experimental development line. ISC had packages and container images queued for later that same day.
BIND is kept by the Internet Systems Consortium, the nonprofit that also hands us dig, delv, and rndc. Its named process can be an authoritative server, a recursive resolver, a forwarder, or all three at once. It runs on about everything, and that ubiquity is precisely why a hole in it earns your attention.
What's actually broken
ISC rates eight of the 14 CVEs as High severity (CVSS 7.5). The rest fall into Medium. Nearly all are remotely triggerable, and several open the door to cache poisoning, the nastiest category of DNS attack because it lets attackers inject forged answers that resolvers take on trust. The remaining ones lean toward denial-of-service, crashing resolvers with crafted packets.
ISC noted it wasn't aware of any active exploitation at publication, on 16 September 2026. The flaws hit public disclosure that day, shortly after an early heads-up on 9 September and a version-list bump on the 11th. So the gap between "we know" and "the whole world knows" measured out in days, not weeks.
Four of the flaws touch DNSSEC integrity. The one ISC spends the most words on is CVE-2026-19033. For secondary zones that gate transfers behind TSIG, named could start serving zone data before the final signed message showed up, and wouldn't roll back if that signature never arrived. The fix now demands a TSIG on every incoming message. ISC points out that modern nameservers sign everything anyway, so you likely won't feel the change.
A second pair revolves around NSEC proofs. CVE-2026-19941 let a bogus NSEC record pass as proof that no wildcard existed, masking a victim's wildcard record and forging an authenticated NXDOMAIN. BIND now insists those proofs come from the same zone. CVE-2026-77119 was a close relative of the same flaw family: a signed NSEC3 from an unrelated sibling zone could masquerade as an "insecurity" proof and downgrade a secure delegation. BIND rejects both when they don't belong.
CVE-2026-78301 is a different beast, and needs a malformed zone with an NS or DNAME node sitting above its origin. Such a zone could register as an authoritative zone cut and send queries inside the configured zone flying off toward out-of-zone delegations. On a server that also recurses, named might follow and cache attacker data for names outside the configured zone. ISC gave this one a higher privilege tag, since it requires a malformed zone loaded via transfer, which is a real bar for an attacker.
The denial-of-service set is where the High-severity ratings pile up. A couple need only one lazy request. CVE-2026-77692 takes a crafted HTTPS (DNS-over-HTTPS) request carrying a cryptographically invalid SIG(0) record, followed by a connection close, and that alone can take named down. CVE-2026-76163 is nearly as effortless: skip the global options block in named.conf, throw a TKEY query at the server, and you get an assertion failure and a hard exit. Not exactly requiring a siege.
The other crashes demand a specific data shape. CVE-2026-19667 fires when a crafted response lands a negative answer exactly 65,536 bytes long, creating a zero-byte negative-cache entry that aborts named on the way back out. CVE-2026-19666 only bites resolvers running dns64 with break-dnssec yes, and only when the bad answer comes from cache. CVE-2026-80274 is a retrieval mismatch: named stores one denial proof at cache time and serves a different one later, then aborts or hands back the wrong record.
The final four are about exhaustion. CVE-2026-19668 pins a resolver to excessive key-tag matching against a delegated zone whose DS/DNSKEY records carry many tags but no valid match. The fix bounds the work with max-validations-per-fetch. CVE-2026-75029 lets a message full of identical SOA/CNAME/DNAME records bloat negative-cache memory; named now keeps just the first copy. The last two ride SVCB/HTTPS AliasMode. CVE-2026-81563 leaks qpcache references when answering an AliasMode query whose target held more than 13 ServiceMode records, pushing the cache past max-cache-size until new lookups start failing. CVE-2026-81736 drives a resolver to do disproportionate CPU work assembling one response from a cached tree of interlinked AliasMode records. Each now carries a per-query cap.
The use-after-free in cached NOQNAME proof data, CVE-2026-19662, affects only the 9.20.x line, up through 9.20.27. It's why 9.20.29 closes all 14 while 9.21.26 closes 13.
If you're on the development branch, 9.21.26 brings the same security fixes plus a notably larger batch of performance work: memory-alignment support in isc_mem, constant-time DNS root-name checks via a new dns_name_isroot(), sharded client UDP refcounts to cut socket contention, and a delegation-specific query path. It also buries the old rootdb, storing root hints inside the delegdb instead.
The stable line isn't just patching holes. 9.20.29 now rejects oversized DNSKEY records up front, catching Ed25519/Ed448 keys with stray trailing bytes that used to slip through silently. It trims a dead "closest encloser" proof cache left unused since BIND 9.9 in 2011. And it repairs a build failure under GCC 16 at -O3. That last one alone will make a few people grumble. For Supported Preview Edition customers, the equivalent patch is 9.20.29-S1.
Where do you go from here?
The CVEs reach across the 9.18, 9.20, and 9.21 lines, but ISC patches only the currently supported versions. Most of the remaining flaws reach up to 9.18.50, 9.20.27, and 9.21.25. The exceptions are the ones already flagged: 19662 stuck on 9.20, and 76163 and 77692 skipping 9.18.
ISC recommends reading the release notes before you upgrade, then moving to the patched release nearest your current version: 9.20.29 for stable, 9.21.26 for development. The full vulnerability-by-version matrix sits in the ISC knowledgebase, and the supported-platforms list lives in the ARM docs plus a separate KB article. If you spot something yourself, ISC wants it filed as a confidential GitLab issue at its bind9 project.
Head here to the download page.
