BIND 9 patches 14 flaws including an unauthenticated DNS-over-HTTPS crash from a single request
On September 16, 2026 the ISC shipped BIND 9.20.29 and 9.21.26 to fix 14 vulnerabilities, including CVE-2026-77692, which crashes named with a single malformed DNS-over-HTTPS request. Inventory every resolver, patch, and make resolution redundant before one packet takes your platform down.
September 16, 2026. The Internet Systems Consortium ships BIND 9.20.29 and 9.21.26 to fix 14 vulnerabilities in the most widely deployed DNS server on the internet. CVE-2026-77692. An unauthenticated attacker crashes the named process with a single malformed DNS-over-HTTPS request. 7.5 on the CVSS scale. Why it matters: DNS is the dependency under every other dependency, and one forged request is enough to stop it.
What the ISC disclosed
BIND 9 is the reference open-source implementation of the DNS, maintained by the Internet Systems Consortium. Its named daemon answers the queries that turn hostnames into IP addresses. Because ISPs, hosters, enterprises, and appliance vendors run it everywhere, a defect never stays inside one network: it propagates to everything that resolves a name downstream.
On September 16, 2026, the ISC released a coordinated security update covering 14 CVEs — seven rated high (CVSS 7.5) and seven medium. BIND 9.20.29 fixes all fourteen; 9.21.26 fixes thirteen, because one flaw does not affect the 9.21 development branch. A matching Supported Preview Edition build was also shipped for customers on that branch.
The headline flaw is CVE-2026-77692, an unauthenticated remote crash. An attacker stops named by sending a DNS-over-HTTPS request carrying a cryptographically invalid SIG(0) signature record, then abruptly closing the transport connection. No authentication, no valid credentials, no multi-step exploit chain: a single forged request is enough. It is exactly the kind of cheap, repeatable denial-of-service primitive that makes DNS teams nervous.
The remaining high-severity flaws are remotely triggerable crashes, memory exhaustion, or resource saturation. The ISC said it had no knowledge of any in-the-wild exploitation at the time of disclosure, and recommends patching without delay.
Why a DNS crash is worse than other denial of service
Denial-of-service flaws are easy to underestimate. They do not leak data and do not hand the attacker a shell, so they get filed beneath the remote-code-execution headlines. DNS is the exception that breaks that instinct: it is the dependency under all the others. When named crashes, resolution stops, and everything that resolves a hostname stops with it — internal service-to-service calls, database connections addressed by DNS, cloud API endpoints, webhook callbacks, email delivery, and the front door your customers knock on. A resolver outage does not degrade a feature; it can swallow an entire platform at once.
The DoH crash makes it worse. DNS-over-HTTPS is increasingly enabled so resolvers stay reachable over ordinary HTTPS, which means the crashing request looks like normal encrypted web traffic and can arrive from anywhere the endpoint is exposed. A single unauthenticated packet that reliably drops the process is a tool an attacker can trigger on repeat, knocking the resolver down as fast as it restarts. If that resolver is a shared internal resolver or an internet-facing service, the blast radius is every client behind it.
The medium flaws are the quiet danger
The medium-severity issues carry a subtler and arguably nastier risk: cache poisoning and arbitrary data injection into DNS zones. Where a crash is loud and obvious, a poisoned cache is silent: it can steer users and services toward attacker-controlled addresses while every dashboard stays green.
The vectors the ISC cites are concrete: forged QTYPE TKEY queries, oversized negative responses, and SVCB/HTTPS records in AliasMode. That is the difference between an outage you notice in seconds and a compromise you might not notice for days — which is why these lower-rated flaws deserve the same patch, not a deferral. DNSSEC validation, where deployed, remains the structural defense against an altered zone.
What you should do
The first lesson is that DNS is infrastructure you own, even when it looks invisible. Plenty of teams patch application dependencies on a tight schedule but let the resolver bundled with a base image, a container, or a network appliance drift, because “it just works”. BIND lives in more places than an asset inventory usually records. Finding every instance — standalone servers, containers, and embedded appliances — is the unglamorous work that decides whether this update actually reaches everything it needs to.
The second lesson is resilience by design. If a single resolver failing takes down your platform, that is an architecture problem this CVE merely exposed. Redundant resolvers, a managed DNS with automatic failover, health checks that pull a dead named out of rotation, and strict limits on who can reach a DoH endpoint turn a one-request crash into a non-event.
The inventory is a single command, followed by the upgrade:
# List named processes and report their version on a host
ps aux | grep -E '[n]amed' || true
named -v 2>/dev/null || /usr/sbin/named -v 2>/dev/null
# On Debian/Ubuntu: check the installed bind9 package version
dpkg-query -W -f='${Version}\n' bind9 2>/dev/null || trueAny resolver still on a 9.20.x earlier than 9.20.29 or a 9.21.x earlier than 9.21.26 should be prioritized, especially if it exposes a DoH endpoint to the internet. Where you cannot patch immediately, restrict which networks can reach DoH, rate-limit at the edge, and make sure a crashing resolver is automatically removed from rotation.
Verdict
CVE-2026-77692 is not code execution, but it is a reminder that DNS availability is a single point of failure for almost everything else. If you run exposed or shared BIND resolvers, patch to 9.20.29 or 9.21.26 today and prioritize anything serving DoH outward. If you lack a current DNS inventory, start there: the instance you forget is the one that stays vulnerable. The real fix is not the patch — it is redundant resolution where a one-request crash is not worth a business outage.