DNS software "BIND" can be tricked into trusting forged answers (CVE-2026-13321) — update to 9.20.26 / 9.21.24

A pair of vulnerabilities (software flaws) has been disclosed for "BIND," the leading software behind the internet's "address directory." Disclosed on July 22, 2026 by its maker, ISC (Internet Systems Consortium), both flaws let an attacker slip forged answers past a defense that is supposed to guarantee they are genuine. Fixed versions were released at the same time.

The one to watch is CVE-2026-13321, rated 8.6 out of 10. If exploited, an attacker 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. The second flaw, CVE-2026-13204 (7.5), lets a crafted query crash BIND itself and halt name resolution.

Both affect older versions and are fixed by updating to the latest release. There are no reports of exploitation so far. This article explains, in plain terms, whether your server is affected, which version to move to, and what to do right now.

What are "BIND" and DNS 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. Both of this month's flaws sit inside that DNSSEC verification process.

The two vulnerabilities disclosed in July 2026

The flaws were published in ISC's official advisories for CVE-2026-13321 and CVE-2026-13204. First, here is which versions are affected and how far to upgrade. Severity is on a 10-point scale: 9+ is "critical," 7–8 is "high."

Both flaws share the same affected range and fixes. Where you need to upgrade depends on which release branch you run.

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. Fixed versions are available from ISC's official download page.

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 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. This is precisely why it matters to update before exploitation spreads.

A closer look at each flaw (technical detail)

From here we examine how each of the two flaws works. If you are not technical, the summary tables above and the remediation section below are all you need.

CVE-2026-13321: firing a signed, forged "proof of non-existence" into a neighboring zone (more 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)—an origin-validation failure (technically CWE-346).

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). To users it looks like "a properly verified, correct answer," leaving no cue to doubt it. NVD (the U.S. vulnerability database) rates it 8.6. There is no workaround; updating is the only fix. The flaw was reported by Qifan Zhang of Palo Alto Networks and fixed in 9.20.26 / 9.21.24.

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

This flaw crashes BIND itself under a crafted condition. DNSSEC has two ways to prove non-existence: NSEC and its privacy-hardened variant NSEC3. According to ISC's advisory, when a domain lacking proper signatures is covered at the parent by both NSEC and NSEC3, with a signature (RRSIG) present for only one of them, BIND hits an internal consistency check during validation and the process terminates (an assertion failure, CWE-617 family).

If BIND goes down, the name resolution it handled stops, and every user behind it struggles to reach the internet at once. An attacker can trigger this without authentication, simply by getting a crafted name queried, making it a denial-of-service issue. It is rated 7.5. Again there is no workaround; updating to 9.20.26 / 9.21.24 resolves it.

Is your server affected, and how to check

First, note that both flaws affect only "resolvers" that perform 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, 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. Checking two things—"is it used as a resolver?" and "is the version in range?"—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. On the 9.20 branch move to 9.20.26 or later; on 9.21, to 9.21.24 or later; on 9.18 or earlier, migrate to 9.20.26. On most Linux distributions you can apply it through the usual update flow—`apt`, `dnf` and so on—once the vendor ships the package. If you build BIND yourself, grab the latest from ISC's official download page.

Neither flaw 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, so plan to run on the assumption that security fixes will land in monthly maintenance releases. Rather than treating this as a one-off, set up a routine of applying updates regularly, and the next advisory will be far less stressful.

Is it being exploited?

As of the July 22, 2026 disclosure, there are no reports of either flaw being used in real attacks. Neither is listed in CISA's catalog of actively exploited vulnerabilities (KEV). 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 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

• ▸ ISC Knowledge Base - CVE-2026-13321: DNSSEC Validation Bypass via Out-of-Zone NSEC Next Field
• ▸ 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)
• ▸ NVD - CVE-2026-13204 (crash with NSEC/NSEC3 both present, CVSS 7.5)
• ▸ SecurityWeek - BIND Updates Patch High-Severity Vulnerabilities
• ▸ ISC Blog - Prepare for more frequent BIND security updates
• ▸ ISC - BIND 9 official downloads