Summary
- ISC disclosed 14 BIND vulnerabilities together on 16 September across several DNS processing paths.
- The flaws include remotely triggered denial of service, DNSSEC validation errors, cache-poisoning risk, and unauthorised zone-content changes.
- Patched current branches include BIND 9.20.29 and 9.21.26.
Internet Systems Consortium has disclosed 14 vulnerabilities in BIND in a security release spanning remote crashes, resource exhaustion, DNSSEC validation, cache integrity, and authentication around incremental zone transfers.
The advisories were published on 16 September and affect different parts of BIND’s authoritative and recursive DNS processing. Several flaws can be triggered remotely and cause the named process to terminate or consume excessive resources, while others affect the integrity of DNS information.
Among the higher-severity issues, CVE-2026-77692 can cause an unauthenticated remote crash through a single DNS-over-HTTPS SIG(0) request. CVE-2026-81736 can force a resolver to spend disproportionate CPU resources constructing responses involving cached SVCB or HTTPS AliasMode records.
Other vulnerabilities involve use-after-free conditions, crafted DNSSEC proofs, DNS64 processing, malformed negative answers, and resource exhaustion caused by excessive cryptographic material.
The release is not limited to availability problems. CVE-2026-77119 can allow an unrelated cached NSEC3 record to be accepted as proof that a secure delegation is insecure. ISC says a successful attacker may then be able to provide a false delegation to an unsigned zone and create a cache-poisoning opportunity.
CVE-2026-19033 affects incremental zone transfers protected by Transaction Signature, or TSIG. BIND can begin serving unauthorised zone-transfer data before the final TSIG verification has completed, and does not roll back to the previous state if a valid signature never arrives.
Those integrity failures carry a different operational consequence from resolver crashes. DNS data determines how users and applications locate services, so unauthorised changes or poisoned cache entries can redirect traffic even while the DNS server itself remains available.
ISC lists BIND 9.20.29 and 9.21.26 among its corrected current releases, with a corresponding Supported Preview Edition update. Individual advisory applicability varies by branch, configuration, and whether a system operates as a resolver, authoritative server, or both.
The scale of the disclosure makes inventory important. An operator cannot assume that every BIND installation is affected by every vulnerability, but neither can it treat the release as a single narrow bug affecting one optional feature.
DNS also sits beneath a large portion of application resilience. Resolver instability can prevent access to otherwise healthy applications, while faults in authoritative infrastructure can make services unreachable even when web, cloud, and backend systems continue operating normally.
DNSSEC adds a further dependency because it is intended to provide cryptographic assurance that DNS responses are authentic. Implementation errors in validation and proof processing can undermine that assurance or turn validation work into a denial-of-service path.
Many organisations will not find BIND in an obvious application inventory. They may consume it through managed DNS providers, Linux distributions, network appliances, cloud systems, or other products that embed the software, leaving suppliers to determine when corrected packages become available.
A fourteen-advisory release across availability, authentication, and integrity therefore creates a broader operational patching problem than an isolated CVE. Operators need to map their actual BIND branches and roles to the ISC advisories, while customers of managed or embedded services need to establish whether the software sits inside dependencies they do not administer directly.
