Practical Linux guidance for safer servers and self-hosted systems.Linux • Security • Self-hosting • Practical tools
Linux Server Basics / Hardening

BIND 9 DNSSEC and Cache-Poisoning Advisories (2026): Which of the Nine CVEs Affect You

On 2026-07-22, ISC disclosed nine vulnerabilities in BIND 9, including two that specifically defeat DNSSEC’s validation guarantees. Ubuntu shipped fixes for eight of the nine in USN-8648-1 (2026-08-19); Debian’s security tracker shows all nine resolved in current point releases. Not every CVE in this batch applies to every BIND deployment — whether you’re exposed depends on whether your server does recursive/validating resolution, uses Response Policy Zones (RPZ), or is simply reachable and parsing untrusted records.

What was disclosed, and does it affect your BIND 9 server?

ISC’s oss-security disclosure lists nine CVEs: CVE-2026-10723, CVE-2026-10822, CVE-2026-11331, CVE-2026-11605, CVE-2026-11622, CVE-2026-11721, CVE-2026-12617, CVE-2026-13204, and CVE-2026-13321. Ubuntu’s USN-8648-1 (2026-08-19) fixes bind9 for 26.04 LTS, 24.04 LTS, and 22.04 LTS, and its own reference list cites eight of these nine — CVE-2026-13204 is notably absent from the USN’s reference list, even though it appears in ISC’s original disclosure and in Debian’s tracker (see below). Debian’s security-tracker source-package page for bind9 lists all nine as resolved, with concrete fixed versions for bullseye, bookworm, and trixie.

None of these are confirmed as actively exploited in the wild; ISC and Ubuntu describe the impact as “could possibly” allow the described attacks, standard advisory language for disclosed-but-unexploited issues.

Which of the nine CVEs apply to your deployment role

The right question isn’t “which CVEs exist” — it’s “which of these actually apply to how I run BIND.” The nine issues split cleanly by role:

CVE Issue Deployment role affected
CVE-2026-10723 NSEC3 impersonation bypasses DNSSEC validation, enabling forged authenticated NXDOMAIN responses Recursive/validating resolvers only
CVE-2026-13321 Validly-signed NSEC records with an incorrect “Next Owner” field bypass DNSSEC validation Recursive/validating resolvers only
CVE-2026-11721 Signed wildcard records with label-count discrepancies enable cache poisoning Recursive/validating resolvers only
CVE-2026-11605 Unnecessary DNSSEC validation causes excessive resource use (DoS) Recursive/validating resolvers, Ubuntu 26.04 LTS only per USN
CVE-2026-11622 Incorrect memory-usage tracking in the DNS cache (DoS) Recursive/caching resolvers
CVE-2026-11331 Wildcard CNAME expansion bypasses RPZ policy RPZ users only
CVE-2026-10822 Malformed PRIVATEDNS key record crashes named (DoS) Any role that parses attacker-supplied records
CVE-2026-12617 CNAME/DNAME ordering issue crashes named (DoS) Any resolving deployment (general parsing bug)
CVE-2026-13204 Domain covered by both NSEC and NSEC3 triggers unexpected exit BIND 9 resolvers handling mixed NSEC/NSEC3 delegations — Ubuntu coverage unconfirmed (see below)

If you run authoritative-only BIND 9 (no recursion, no validation) and don’t use RPZ, the two DNSSEC-bypass CVEs and the cache-poisoning CVE don’t apply to your role — but the two general crash bugs (CVE-2026-10822, CVE-2026-12617) still do, since they’re triggered by parsing malformed input rather than by a specific resolution mode.

If you run BIND as a recursive, DNSSEC-validating resolver (the common self-hosted-DNS setup), all nine issues are relevant to check, since your server performs exactly the validation and caching logic these CVEs target.

If you use Response Policy Zones for DNS-based filtering, CVE-2026-11331 is a direct policy-bypass concern regardless of your recursive/authoritative split.

CVE-2026-13204 is the one open item here: it’s in ISC’s original disclosure and Debian’s resolved-issue list for bind9, but it does not appear in USN-8648-1’s own reference list. That could mean it doesn’t affect the Ubuntu-packaged version, or that the USN’s reference list is simply incomplete — this research pass could not confirm which. Ubuntu users should not assume this specific CVE is covered by USN-8648-1 without checking further.

Why two of these are a DNSSEC trust-boundary failure, not just a bug

Most of the nine issues are denial-of-service bugs: a malformed input crashes or exhausts a server. Two are different in kind, because they defeat the specific guarantee DNSSEC validation exists to provide — proof that a “domain doesn’t exist” or “this record set is authentic” response hasn’t been tampered with.

CVE-2026-10723 lets BIND accept an incorrect child-zone NSEC3 record as valid, which can be used to forge an authenticated NXDOMAIN response — the resolver ends up trusting a fabricated “this name doesn’t exist” answer as if it were properly signed. CVE-2026-13321 works the other direction: a validly-signed NSEC record with an incorrect “Next Owner” field passes validation when it shouldn’t, again undermining DNSSEC’s authenticated-denial-of-existence mechanism.

If your reason for running DNSSEC validation is specifically to prevent spoofed answers — the whole point of deploying it — these two CVEs are the ones to prioritize, because they attack that exact property rather than causing an outage you’d notice immediately. Both require your resolver to actually be performing validation; they don’t apply to authoritative-only or non-validating configurations. This is the same access-layer trust-boundary logic that applies to any component sitting in an authentication or verification path: the guarantee is only as good as the unpatched code enforcing it.

Fixed versions: Ubuntu, Debian, and upstream

Ubuntu, per USN-8648-1 (2026-08-19):

Debian, per the security-tracker’s current resolved-issue status (checked 2026-08-22):

No separately numbered Debian Security Advisory for this specific nine-CVE batch was located in this research pass, despite the tracker showing all nine resolved with concrete package versions. Debian sometimes rolls security-relevant fixes into point releases without a distinct DSA number for every batch. Check your installed version against the tracker directly rather than waiting for a DSA announcement to confirm you’re covered.

Upstream, per the ISC BIND 9 Software Vulnerability Matrix: the fixed release is 9.20.26. The 9.18 branch reached end-of-life on 2026-07-22, the same day this batch was disclosed — if you’re still on 9.18.x from a source build or third-party package, there is no further upstream fix for that branch; you need to move to the 9.20 or 9.21 line.

Sources and next steps

  1. Identify your BIND 9 role: authoritative-only, recursive/validating, or RPZ-filtering (or some combination).
  2. Cross-check the role-based table above against the CVE list for your distro’s advisory.
  3. Confirm your installed BIND 9 version against the fixed versions above for your distribution.
  4. If you’re unsure whether Ubuntu’s USN-8648-1 covers CVE-2026-13204 for your release, check the CVE’s individual Ubuntu tracker page directly rather than assuming coverage from the USN summary.

Primary sources:

The same discipline of checking which CVEs actually apply to your specific configuration — rather than treating every disclosed CVE as equally urgent — applies to any package advisory, including the Caddy DSA-6429-1 batch covered here previously.