The short answer
An unpatched BIND resolver can be crashed by a single request. On September 16, 2026 ISC disclosed 14 vulnerabilities in BIND 9 — seven high severity (CVSS 7.5), seven medium — and shipped fixes in BIND 9.20.29 and 9.21.26. The most striking is CVE-2026-77692: an unauthenticated attacker crashes the named process by sending one malformed DNS-over-HTTPS request with a cryptographically invalid SIG(0) record and closing the connection early. Other flaws enable memory exhaustion, cache poisoning, and injection of arbitrary data into DNS zones. ISC says it is not aware of exploitation in the wild; the remediation is to update immediately.
For US and EU teams, the point is not one CVE — it is that DNS is the dependency under every other dependency. If name resolution stops, so does everything that resolves a hostname, from your API gateway to your payment processor callback. That is why DNS belongs in the same patch cadence and resilience design as the rest of your cloud and DevOps platform, not in a box marked “set and forget.”
What ISC disclosed
BIND 9 is the reference open-source implementation of the Domain Name System, maintained by the Internet Systems Consortium (ISC) and run by internet service providers, hosting companies, enterprises, and appliance vendors around the world. Its named daemon answers the DNS queries that turn hostnames into IP addresses. Because so much infrastructure resolves names through BIND, a defect in it does not stay in one network — it ripples out to everything downstream of resolution.
On September 16, 2026, ISC published a coordinated security update covering 14 CVEs and released BIND 9.20.29 and 9.21.26 to fix them. Seven of the issues are rated high severity with a CVSS score of 7.5, and seven are medium. BIND 9.20.29 addresses all fourteen; BIND 9.21.26 addresses thirteen, because one of the flaws does not affect the 9.21 development branch. ISC also shipped a corresponding Supported Preview Edition build for customers on that track.
The most eye-catching flaw is CVE-2026-77692 (CVSS 7.5), an unauthenticated remote crash. An attacker can terminate named by transmitting a single DNS-over-HTTPS (DoH) request that contains a cryptographically invalid SIG(0) signature record and then abruptly closing the transport connection. No authentication, no valid credentials, and no multi-step exploit chain are required — one crafted request is enough to take the resolver down, which is exactly the kind of cheap, repeatable denial-of-service primitive that makes DNS teams nervous. The remaining high-severity issues are also remotely triggerable crashes, memory exhaustion, or resource depletion. Reachable, low-cost, and aimed at core plumbing is precisely the risk profile a penetration test and security audit is meant to surface before an attacker does. ISC stated that it is not aware of any of the resolved bugs being exploited in the wild, and it recommends updating without delay.
Why a DNS crash is worse than it sounds
Denial-of-service bugs are easy to underrate. They do not leak data or hand an attacker a shell, so they get filed below the remote-code-execution headliners. But DNS is the exception that breaks that instinct: it is the dependency under every other dependency. When named crashes, name 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 hit. A resolver outage does not degrade one feature; it can black-hole a whole platform at once.
The DoH crash sharpens that further. DNS-over-HTTPS is increasingly enabled so resolvers can be reached over ordinary HTTPS, which means the crashing request looks like normal encrypted web traffic and can arrive from anywhere the endpoint is reachable. A single unauthenticated packet that reliably drops the process is a denial-of-service tool an attacker can fire repeatedly, keeping a 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-severity issues carry a quieter but 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. That is the difference between an outage you notice in seconds and a compromise you may not notice for days, which is why these lower-scored flaws still deserve the same patch, not a deferral.
What it means for US & EU software teams
The first lesson is that DNS is infrastructure you own, not a utility you rent — even when it feels invisible. Plenty of teams patch their 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 ships inside more places than an asset list usually captures. Finding every instance — standalone servers, containers, and embedded appliances — is the unglamorous work that decides whether this update actually lands everywhere it needs to.
The second lesson is resilience by design so one crash is not an outage. If a single resolver failing takes your platform down, that is an architecture problem this CVE merely exposed. Redundant resolvers, managed DNS with automatic failover, health checks that pull a dead named out of rotation, and tight limits on who can reach a DoH endpoint all turn a one-request crash from a business incident into a non-event. Assume infrastructure components will fail; design so name resolution survives when one does.
Third, this is an availability-and-integrity obligation, not just an ops ticket. For EU teams, DORA makes ICT resilience and third-party component management explicit for financial entities, and NIS2 raises the bar for essential and important services; for US teams in FinTech and health, availability and integrity of core systems sit squarely inside SOC 2 and HIPAA expectations. A DNS outage or a poisoned zone is exactly the kind of event those frameworks ask you to prevent, detect, and evidence. Being able to show which resolvers ran the affected versions, when you patched, and how resolution stays up during a component failure is the record auditors will look for.
What to do now
- Inventory every BIND instance. Find all resolvers and authoritative servers running BIND 9 — standalone hosts, containers and base images, and appliances or products that embed it. The instances you forget are the ones that stay vulnerable.
- Update to the fixed builds. Move to BIND 9.20.29 or 9.21.26 (or the matching Supported Preview Edition build). Treat internet-facing resolvers and anything exposing DNS-over-HTTPS as the top priority, since CVE-2026-77692 needs only one unauthenticated request.
- Reduce exposure where you cannot patch instantly. Restrict which networks and clients can reach the DoH endpoint, rate-limit and filter at the edge, and make sure a crashing resolver is automatically removed from rotation so clients fail over instead of hanging.
- Watch for poisoning, not just crashes. The medium-severity issues can inject data into caches and zones silently. Monitor for unexpected records, validate responses with DNSSEC where you can, and alert on
namedrestarts and answer anomalies, not only on downtime. - Build in redundancy and test it. Run more than one resolver, consider managed or secondary DNS for critical zones, and add DNS servers and their exposed protocols to the scope of your next penetration test so this layer stops being a blind spot.
Frequently asked questions
What was fixed in BIND 9.20.29 and 9.21.26?
ISC patched 14 vulnerabilities in BIND 9, disclosed on September 16, 2026 — seven high severity (CVSS 7.5) and seven medium. BIND 9.20.29 fixes all 14; BIND 9.21.26 fixes 13, because one issue does not affect the 9.21 branch. ISC recommends updating to the fixed versions immediately.
What is CVE-2026-77692?
It is an unauthenticated remote crash of the BIND named process, rated CVSS 7.5. An attacker terminates the server by sending a single malformed DNS-over-HTTPS request carrying a cryptographically invalid SIG(0) signature record, then closing the connection prematurely. One request is enough, and no authentication is required — a cheap, repeatable denial-of-service path against any BIND resolver exposing a DoH endpoint.
Are these flaws being exploited in the wild?
As of disclosure on September 16, 2026, ISC said it is not aware of any of the resolved bugs being exploited. That is not a reason to wait: the DoH crash needs one unauthenticated request, several other high-severity flaws are remotely triggerable denial-of-service issues, and a DNS outage cascades across every service that relies on name resolution.
What do the other BIND vulnerabilities allow?
The remaining high-severity issues let remote attackers cause crashes, memory exhaustion, or resource depletion, all resulting in denial of service. The medium-severity issues can cause cache poisoning, excessive memory or CPU use, or arbitrary data injection into DNS zones, via techniques such as crafted QTYPE TKEY queries, oversized negative responses, and SVCB/HTTPS AliasMode records. Cache poisoning is the most dangerous because it can silently redirect traffic.
What should teams running BIND do now?
Inventory every BIND resolver and authoritative server, including containers and appliances that embed BIND, and update to 9.20.29, 9.21.26, or the matching Supported Preview Edition build. Prioritize internet-facing resolvers and DoH endpoints, restrict who can reach DoH where you cannot patch instantly, run redundant or managed DNS so one crashing resolver does not down resolution, and add DNS to your next penetration test scope.
Sources
ISC Knowledge Base — CVE-2026-77692: Unauthenticated remote crash of named via a single DoH SIG(0) request
SecurityWeek — ISC Patches 14 Vulnerabilities in BIND 9 Security Update
The Hacker News — BIND 9 Update Fixes 14 Flaws, Including an Unauthenticated Crash Over DNS-over-HTTPS