DNS software "BIND" hit by nine flaws that can block sites or crash the server (CVE-2026-13321 and more) — update to 9.20.26 / 9.21.24

Nine vulnerabilities (software flaws) have been disclosed for "BIND," the leading software behind the internet's "address directory," in the July 2026 scheduled security update. Its maker, ISC (Internet Systems Consortium), announced them together, and fixed versions were released the same day.

The ones to watch most are the family that makes BIND trust an attacker's forged answers as genuine. Chief among them, CVE-2026-13321, rated 8.6 out of 10, can plant a false answer—such as "that address does not exist"—into BIND's cache for a targeted site, cutting off everyone who uses that server from reaching it. The nasty part is that the forged answer passes the digital-signature check and arrives wearing a "verified as genuine" badge. Most of the rest are denial-of-service (DoS) flaws that crash BIND itself with a crafted query.

All nine affect older versions and are fixed by updating. The fixed releases are 9.20.26 / 9.21.24, and there are no reports of exploitation so far. This article explains, in plain terms, what each of the nine is, whether your server is affected, and which version to move to.

The nine vulnerabilities disclosed in July 2026

First, the big picture. Severity is on a 10-point scale: 9+ is "critical," 7–8 is "high," and 4–6 is "medium." This time the main target across the board is the caching DNS (resolver) that performs name resolution (the difference in roles is explained later).

Of the nine, three are "spoofing / cache-poisoning" flaws that make BIND trust forged answers, five are "denial-of-service (DoS)" flaws that stop BIND, and one bypasses a defense rule. We look at each in those three groups below.

Flaws that make BIND trust forged answers (most dangerous)

The first group makes BIND trust an attacker's false data as a "verified, correct answer." To users it looks properly checked, so there is no cue to doubt it and the damage is hard to notice. If you are not technical, the first line or two of each item is enough to get the gist.

CVE-2026-13321: firing a signed, forged "proof of non-existence" into a neighboring zone (8.6, most dangerous)

This is the headline flaw. DNSSEC uses a record called NSEC to prove, with a signature, that a name "does not exist." NSEC has a field for the "next existing name," which is how it proves "nothing exists between A and B." But BIND's resolver (the side that performs name resolution) accepted these records even when that "next name" field pointed outside the signer's own zone (its area of authority).

Abusing this, an attacker can craft, from a signed zone they control, a forged NSEC that spans into someone else's zone. ISC calls this "cross-zone cache poisoning," and notes the false data lingers in the cache stamped as "signature-verified" (AD=1). NVD (the U.S. vulnerability database) rates it 8.6. There is no workaround; updating is the only fix. It was reported by Qifan Zhang of Palo Alto Networks and fixed in 9.20.26 / 9.21.24.

CVE-2026-11721: cache poisoning by exploiting a label-count discrepancy (7.5)

This one also burns false data into the cache. If an attacker crafts a response containing a signature (RRSIG) with fewer labels (the dot-separated levels) than the real zone, BIND generates a wildcard entry shorter than intended and false information is left in the cache. ISC describes it as "cache poisoning combining a label-count discrepancy, RRSIG, and wildcards." It requires the setting that synthesizes answers from DNSSEC (synth-from-dnssec, on by default) — a condition many environments meet, so take note. Like 13321, it was reported by Qifan Zhang of Palo Alto Networks. Rated 7.5, fixed in 9.20.26 / 9.21.24.

CVE-2026-10723: making BIND trust a forged "it does not exist" (6.8)

Here, BIND improperly accepts NSEC3 records (one method of proving non-existence) in forms it should reject. Abusing this, an attacker can make BIND trust a forged "no such name (NXDOMAIN)" about a neighboring zone as if it were verified. It leads to the same kind of DNS spoofing as 13321, but at a somewhat lower severity of 6.8. The fix is again 9.20.26 / 9.21.24, and there are no reports of exploitation.

Flaws that take the service down (crashes and resource exhaustion)

The second group is denial-of-service (DoS): crafted queries or responses crash BIND, or exhaust its CPU or memory, so that name resolution stops. Five flaws fall here. When BIND goes down, the employees or ISP customers behind that server all struggle to reach the internet at once.

CVE-2026-13204: BIND crashes when NSEC and NSEC3 coexist (7.5)

When a domain lacking proper signatures is covered at the parent by both NSEC and its privacy-hardened variant NSEC3, with a signature (RRSIG) present for only one of them, ISC's advisory says BIND hits an internal consistency check during validation and the process terminates. An attacker can trigger this without authentication, simply by getting a crafted name queried. It is rated 7.5 and resolved in 9.20.26 / 9.21.24.

CVE-2026-12617: BIND crashes from CNAME/DNAME ordering (7.5)

When records for aliases—CNAME (an alias) or DNAME (an alias that redirects a whole subtree)—arrive in a particular order or combination, BIND hits an internal consistency check and terminates. For example, a delayed negative DNAME response arriving after a positive answer can be the trigger. An attacker can stop BIND without authentication, just by returning a crafted response. Rated 7.5, fixed in 9.20.26.

CVE-2026-11622: memory use exceeds the configured limit (7.5)

Under a "random subdomain attack"—flooding queries for non-existent subdomains—BIND's memory use can balloon far past the configured ceiling (max-cache-size), slowing responses or causing memory exhaustion. The problem is that it can overshoot the limit by orders of magnitude. Rated 7.5, it affects DNSSEC-validating resolvers and is fixed in 9.20.26 / 9.21.24.

CVE-2026-11605: CPU wasted by over-validating signatures (7.5)

When a response contains more signatures (RRSIG) than necessary, BIND keeps validating them needlessly and consumes excessive CPU. An attacker can use this to make processing heavy and stall name resolution. Rated 7.5, affecting the 9.20 and 9.21 branches; updating to 9.20.26 / 9.21.24 resolves it.

CVE-2026-10822: crash from a PRIVATEDNS-algorithm key record (6.5)

Abusing PRIVATEDNS, a mechanism that lets you specify a custom signing algorithm, an attacker who gets BIND to process a key (KEY) record with an invalid value can cause 9.20 and 9.21 to exit unexpectedly. It happens when the crafted record is processed and stored, and no authentication is required. Rated 6.5, fixed in 9.20.26 / 9.21.24.

A flaw that slips past a defense rule

CVE-2026-11331: slipping past a filter (RPZ) with a wildcard (7.5)

RPZ (Response Policy Zones) is, in effect, a "DNS filter" that blocks name resolution for dangerous domains. This flaw is a defect in wildcard CNAME policy handling that lets an attacker slip past that defense—or crash BIND. According to ISC's advisory, it is rated 7.5. Only environments that use wildcard CNAME policies in RPZ are affected; if you do not use RPZ, it does not apply. If you do, update to 9.20.26 / 9.21.24.

What are "BIND," DNS, and DNSSEC in the first place?

When we type a text address like "example.com," the computer first converts it into a numeric address like "203.0.113.10" before communicating. This conversion is handled by DNS (the Domain Name System), effectively the internet's "address directory." If it stops, or returns the wrong address, email and the web all fail at once.

BIND is the oldest and most widely used software for running DNS. It underpins the internet inside corporate networks, ISPs, cloud providers, and government agencies alike. Most people rely on BIND without ever knowing the name. That is exactly why a BIND flaw tends to have broad reach—much like the flaws we covered in "dnsmasq," the DNS software in home routers and in "Netty," a networking component for Java.

One more mechanism matters here: DNSSEC. It uses digital signatures to confirm that a DNS answer was not swapped out along the way—think of it as stamping an official seal on the address directory. Many of this month's nine flaws sit inside that DNSSEC verification process. The frustrating part is that the very mechanism meant to guarantee correct answers became the entry point for spoofing and server crashes.

Who targets this, and what do they do?

Severity numbers and jargon alone make it hard to judge whether this is your problem. Here is a plain-language look, centered on the more dangerous spoofing flaws (especially CVE-2026-13321), at who does this, for what, and with what damage.

The people who can exploit this are attackers who can set up even a single signed domain of their own. No special position is required. Simply registering a cheap domain and turning on DNSSEC (digital signing) gives them a foothold. They do not need to break into the target's server, and just about anyone can prepare it—that is what makes it dangerous.

What the attacker aims to do is borrow the signing power of their own domain to make BIND believe false answers about someone else's domain. A signature is supposed to apply only within its own domain, but this flaw lets a crafted record "spill over" into a neighboring domain. As a result, a false "does not exist" reply about, say, a bank or an internal system can be burned into the cache as a verified, legitimate answer.

The damage hits everyone who uses that BIND server at once. Employees or ISP customers sharing the same DNS server lose access to the targeted site for a period of time. To an end user it looks like "one specific service suddenly won't open," which also makes the cause hard to pin down. For the organization running it, that means outages, a flood of support inquiries, and eroded trust. The DoS flaws end the same way—if BIND goes down, everyone's traffic stops. This is precisely why it matters to update before exploitation spreads.

Is your server affected, and how to check

First, note that the main target of all nine is the "resolver" that performs name resolution. A DNS server plays one of two broad roles: a caching DNS (full resolver) that answers users' queries by looking names up, or an authoritative server that publishes your own domain's records to the outside. Because these flaws involve DNSSEC validation and resolver response handling, a server used only as an authoritative DNS is essentially not affected. Start by confirming which role your BIND plays.

Next, check your version. In most environments named -v prints it. If it falls within the affected range above (9.20.24 or earlier, 9.21.23 or earlier, etc.), you are affected. Whether DNSSEC validation is enabled also matters—but current BIND enables validation by default, so unless you deliberately turned it off, assume "validating" to be safe. Some flaws only apply under specific settings, such as CVE-2026-11331, which is relevant only if you use RPZ. Checking two things—"is it used as a resolver?" and "is the version in range?"—largely tells you whether you are affected.

For foundational software like BIND that runs everywhere, keeping track of "which server runs which version" saves scrambling every time an advisory lands. The idea of matching the components you use against known flaws is something we also cover in our article on a way to surface flaws in open-source components.

What to do right now

The fix is simple: update to a fixed release. Where you upgrade depends on your branch.

The key point is that the fixes are 9.20.26 and 9.21.24. The long-lived 9.18 branch has no fixed release this time, so anyone on 9.18 or earlier must move to the 9.20 branch. On most Linux distributions (Ubuntu, Debian, RHEL, SUSE and so on) you can apply it through the usual update flow—apt, dnf and the like—once the vendor ships the package. If you build BIND yourself, grab the latest from ISC's official download page.

None of these flaws has a viable workaround (a temporary config-only mitigation). Disabling DNSSEC validation would in theory reduce exposure, but that throws away the signature-checking security feature itself and invites other risks, so it is not recommended. Updating is the one and only best move.

Note that ISC has warned that BIND security updates will become more frequent through 2026, and this batch of nine is part of that shift. Plan to run on the assumption that security fixes land in monthly maintenance releases, and set up a routine of applying updates regularly—the next advisory will be far less stressful.

Is it being exploited?

As of the July 2026 disclosure, there are no reports of any of the nine being used in real attacks. None is listed in CISA's catalog of actively exploited vulnerabilities (KEV) (you can check the latest status on the CISA KEV dashboard). ISC states that most were "found in internal testing, with no known exploits." This disclosure followed the normal process—ISC prepared fixes after receiving the reports, then announced—rather than reacting after attacks began. Security outlets abroad, including SecurityWeek, likewise report no exploitation at this time.

That said, BIND underpins DNS worldwide, and poisoning or stopping a single resolver affects every user behind it—so it is a high-value target. With the details now public, we cannot rule out attackers trying to exploit them. Rather than scrambling once exploitation begins, quietly moving to a fixed release now—while no attacks are reported—is the surest, lowest-effort defense. Stay calm, but do not put it off.

References

• ▸ JVNVU#97496543 - Multiple vulnerabilities in ISC BIND (July 2026)
• ▸ ISC Knowledge Base - CVE-2026-13321: DNSSEC Validation Bypass via Out-of-Zone NSEC Next Field
• ▸ ISC Knowledge Base - CVE-2026-11721: Cache poisoning with label count discrepancy, RRSIG, and wildcards
• ▸ ISC Knowledge Base - CVE-2026-13204: Unexpected exit with NSEC and NSEC3 both present
• ▸ NVD - CVE-2026-13321 (DNSSEC validation bypass / cache poisoning, CVSS 8.6)
• ▸ SecurityWeek - BIND Updates Patch High-Severity Vulnerabilities
• ▸ ISC Blog - Prepare for more frequent BIND security updates
• ▸ ISC - BIND 9 official downloads