The bouncer accepts an ID that vouches for someone standing in a different bar
BIND's validator was supposed to enforce that an NSEC record's *Next Domain Name* field stays inside the zone that signed it — that's the whole point of the authenticated-denial chain in DNSSEC. This bug means a validly-signed NSEC from attacker.tld can name-range across into victim.tld, and BIND will accept the AD=1 (authenticated denial) answer as gospel. Anyone who can register a DNSSEC-signed zone (i.e., anyone with $10 and a registrar account) can inject authenticated non-existence proofs for arbitrary names in other people's zones, poisoning the resolver cache with a cryptographically blessed lie. Affected: BIND 9.11.0–9.18.50, 9.20.0–9.20.24, 9.21.0–9.21.23, plus the -S1 Supported Preview branches through 9.20.24-S1.
ISC rated this HIGH (8.6) with vector AV:N/AC:L/PR:N/UI:N/S:C/C:N/I:H/A:N. The vector is right — network reachable, no auth, scope-changed, integrity-only — but the HIGH label undersells the deployment context. BIND 9 is *the* resolver that ships with every RHEL/Debian/Ubuntu box and runs on a huge share of enterprise and ISP recursive resolvers. A cache-poisoning primitive against the recursive tier is not a per-host bug; one poisoned cache lies to every downstream client. We upgrade to CRITICAL on role multiplier and blast radius, not on friction.
5 steps from start to impact.
Attacker stands up a DNSSEC-signed authoritative zone they control
ldns-signzone, dnssec-signzone, or Knot DNS all do it in one command. No exotic capability required.- ability to register or lease a DNSSEC-enabled domain
- any authoritative nameserver the attacker controls
- none — costs less than a coffee
Craft an NSEC record whose Next Domain Name crosses into the victim zone
a.attacker.tld → login.victim-bank.tld, signs it with their own zone's ZSK, and serves it. In a compliant validator this fails the in-zone check. In vulnerable BIND, the signature verifies and the range is accepted.- knowledge of a victim name to poison (public knowledge)
- control of the signing keys for the attacker's zone
- requires the crafted NSEC to actually be queried and cached — see next step
Induce the victim resolver to query the attacker's zone
attacker.tld — phishing link, ad-network beacon, email HTML pixel, an image on a compromised site, or wait for organic traffic. The resolver contacts the attacker's authoritative NS, receives the malicious NSEC + RRSIG, validates the signature, and caches the authenticated denial for login.victim-bank.tld.- any client can be nudged into a single DNS lookup
- resolver is BIND 9 within the affected version bands with DNSSEC validation enabled (
dnssec-validation auto|yes— the default)
- negligible — DNS lookups happen constantly and are trivial to induce
Downstream clients receive the authenticated lie
_dmarc, _mta-sts, SPF, DKIM selectors. Denying a CAA record enables mis-issuance windows; denying _mta-sts downgrades mail TLS; denying DMARC/DKIM enables spoofing.- poisoned entry lives in cache for the TTL
- downstream application trusts DNS (essentially all of them do)
- scoped to what NSEC denial can express — this is integrity-of-denial, not arbitrary A-record injection; still enormous
Chain into higher-impact primitives
_dmarc, _domainkey, and MTA-STS records for a target domain is a phishing enabler at fleet scale.- patient attacker, long TTL, iterative poisoning of related names
- defenders using DoH/DoT egress to non-BIND upstreams (Google/Cloudflare/Quad9) sidestep this
The supporting signals.
| In-the-wild status | No confirmed exploitation per ISC advisory as of 2026-07-22. Not KEV-listed. |
|---|---|
| PoC availability | No public PoC at disclosure. Trivial to build with ldns-signzone + custom NSEC crafting; expect weaponized code within 2–4 weeks. Reporter Qifan Zhang (Palo Alto Networks) presumably holds a working PoC. |
| EPSS | New CVE — EPSS not yet meaningful; expect rapid climb given resolver-tier impact. |
| KEV | Not listed (2026-07-23). |
| CVSS vector | CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:N/I:H/A:N — network, no auth, scope-changed integrity impact. Vector correct; label undersells resolver blast radius. |
| Affected versions | BIND 9.11.0–9.18.50, 9.20.0–9.20.24, 9.21.0–9.21.23, 9.11.3-S1–9.18.50-S1, 9.20.9-S1–9.20.24-S1. |
| Fixed versions | BIND 9.18.51, 9.20.25, 9.21.24 (and -S1 equivalents). Debian/Ubuntu/RHEL backports typically land within 24–72h of ISC release — check security-tracker.debian.org and RHSA feeds. |
| Exposure data | Shodan shows ~1.4M open recursive resolvers globally with BIND banners; the far larger population is internal enterprise/ISP resolvers where exposure isn't scanner-visible. Every DNSSEC-validating BIND resolver is affected, internet-facing or not. |
| Disclosure | 2026-07-22 — ISC KB cve-2026-13321. |
| Credit | Qifan Zhang, Palo Alto Networks. |
noisgate verdict.
The single decisive factor is the role multiplier: BIND is the recursive resolver of record in ~40%+ of enterprise and ISP infrastructure, and this bug corrupts the DNSSEC trust boundary itself — one poisoned resolver lies to every downstream client. That inverts the normal per-host math and floors the verdict at CRITICAL despite the CVSS 8.6 label.
Why this verdict
- Role multiplier — recursive resolver tier: BIND 9 with
dnssec-validationis a canonical high-value component. A single poisoned cache serves an entire enterprise or ISP subscriber base; chain outcome is fleet-scale integrity failure. Floor: CRITICAL. - Trivial precondition: attacker only needs a registered DNSSEC-signed domain (~$10) and one lookup triggered from behind the victim resolver. No auth, no user interaction, no privileged position.
- Scope-changed integrity primitive: authenticated (AD=1) denial responses undermine security-sensitive DNS records — CAA, MTA-STS, DMARC/DKIM, OCSP, HSTS discovery. Downstream impact reaches TLS trust, email authentication, and cert issuance.
- No workaround per ISC — the only fix is upgrading BIND or disabling DNSSEC validation (which itself weakens security posture).
- Friction adjustment: the bug requires DNSSEC validation to be enabled, which is BIND's default and is on in most modern deployments; this doesn't meaningfully narrow the population.
Why not higher?
Availability and confidentiality impact are indirect — the bug is integrity-of-denial, not arbitrary RRset injection. You cannot directly redirect bank.com to an attacker IP; you can only assert non-existence of names. That ceiling keeps it out of the 9.8+ 'internet-on-fire' bracket like a resolver RCE would command.
Why not lower?
Downgrading below HIGH would require ignoring that BIND is the resolver used by a huge share of the internet's recursive tier and that the bug is in the DNSSEC validation path — the exact code path that's supposed to be the trust anchor. Deployment-role blast radius floors this at CRITICAL; friction is minimal (any registered signed zone will do).
What to do — in priority order.
- Upgrade BIND to 9.18.51 / 9.20.25 / 9.21.24 (or distro-backported equivalent) — The only real fix. Roll to canary resolvers first, then production recursive tier. Deploy within 3 days per noisgate CRITICAL mitigation SLA — BIND upgrades are low-drama and the process is well-rehearsed on most fleets.
- Temporarily route recursive DNS to a non-BIND validator — If patching is blocked, forward client resolvers to Unbound, Knot Resolver, or a trusted public resolver (1.1.1.1, 8.8.8.8, 9.9.9.9) via DoT so a compromised transit link can't strip DNSSEC. Buys days, not weeks.
- Shorten resolver cache max-TTL to reduce poisoning dwell — Set
max-cache-ttl 300andmax-ncache-ttl 300innamed.conf. Doesn't prevent poisoning but caps the damage window to 5 minutes per injection. - Deploy RPZ (Response Policy Zone) rules covering high-value internal names — For critical brand and internal names, an authoritative RPZ override on the resolver ensures a local answer wins over any cached NSEC denial.
- Add monitoring for anomalous NXDOMAIN spikes on security-critical names — Alert on unexpected NXDOMAIN for
_dmarc.*,_mta-sts.*,caaqueries, and OCSP hosts. This is the wire-level tell of an in-progress poisoning campaign.
- Disabling DNSSEC validation — technically stops this bug but throws away the very defense against Kaminsky-class attacks. Net posture is worse.
- Firewalling inbound port 53 — recursive resolvers make *outbound* queries; the poison arrives as an answer to a legitimate query. Perimeter ACLs on 53/udp don't help.
- TLS everywhere — TLS validates certs against DNS-derived hostnames, but CAA/MTA-STS/HSTS-discovery all sit on DNS. Denial-of-existence for those records enables downgrade attacks TLS can't see.
- Rate-limiting or DNS RRL — RRL is about outbound amplification abuse, not inbound answer validation. Wrong plane.
Crowdsourced verification payload.
Run on each BIND resolver host as any user (root not required for named -v). Example: ./check-cve-2026-13321.sh. Compares installed BIND version against ISC's fixed release matrix and reports VULNERABLE / PATCHED / UNKNOWN.
#!/usr/bin/env bash
# check-cve-2026-13321.sh — BIND DNSSEC NSEC out-of-zone validation bypass
# Exit codes: 0 PATCHED, 1 VULNERABLE, 2 UNKNOWN
set -u
BIN=$(command -v named || true)
if [[ -z "$BIN" ]]; then
echo "UNKNOWN: named binary not found in PATH"
exit 2
fi
RAW=$("$BIN" -v 2>/dev/null | head -n1)
# Examples: "BIND 9.18.28-1~deb12u2-Debian" or "BIND 9.20.24-S1"
VER=$(echo "$RAW" | awk '{print $2}' | sed 's/-.*//')
SUFFIX=$(echo "$RAW" | awk '{print $2}' | grep -oE 'S1' || true)
if [[ -z "$VER" ]]; then
echo "UNKNOWN: could not parse version from: $RAW"
exit 2
fi
IFS=. read -r MAJ MIN PATCH <<< "$VER"
MAJ=${MAJ:-0}; MIN=${MIN:-0}; PATCH=${PATCH:-0}
vuln=2
case "$MIN" in
11|12|13|14|15|16|17)
# 9.11.x–9.17.x all affected in the 9.11.0–9.18.50 band
vuln=1 ;;
18)
if (( PATCH <= 50 )); then vuln=1; else vuln=0; fi ;;
20)
if (( PATCH <= 24 )); then vuln=1; else vuln=0; fi ;;
21)
if (( PATCH <= 23 )); then vuln=1; else vuln=0; fi ;;
*)
vuln=2 ;;
esac
# Confirm DNSSEC validation is on — bug only bites when validating
VALSTATE="unknown"
if command -v named-checkconf >/dev/null 2>&1 && [[ -r /etc/bind/named.conf || -r /etc/named.conf ]]; then
CONF=$( [[ -r /etc/bind/named.conf ]] && echo /etc/bind/named.conf || echo /etc/named.conf )
if grep -Eq 'dnssec-validation[[:space:]]+(auto|yes)' "$CONF" 2>/dev/null; then
VALSTATE="enabled"
elif grep -Eq 'dnssec-validation[[:space:]]+no' "$CONF" 2>/dev/null; then
VALSTATE="disabled"
else
VALSTATE="default(auto=enabled)"
fi
fi
case $vuln in
0) echo "PATCHED: BIND $VER${SUFFIX:+-$SUFFIX} (validation=$VALSTATE)"; exit 0 ;;
1) echo "VULNERABLE: BIND $VER${SUFFIX:+-$SUFFIX} affected by CVE-2026-13321 (validation=$VALSTATE)"; exit 1 ;;
*) echo "UNKNOWN: BIND $VER${SUFFIX:+-$SUFFIX} — unrecognized version band"; exit 2 ;;
esac
If you remember one thing.
named -v, flag anything in the affected bands, and cut a change ticket for the 9.18.51 / 9.20.25 / 9.21.24 upgrade. Per the noisgate mitigation SLA for CRITICAL, you have ≤ 3 days to either upgrade the resolver tier or forward recursive traffic to a non-BIND validator (Unbound, Knot Resolver, or a hardened public resolver over DoT). Per the noisgate remediation SLA, the actual patched BIND package must be in place fleet-wide within ≤ 90 days, but resolver-tier rollouts are usually painless enough that most shops should finish inside 14 days. No KEV listing and no confirmed exploitation yet — but the exploitation cost is a $10 domain and one triggered lookup, so treat the PoC clock as running.Sources
- ISC KB — CVE-2026-13321 advisory
- Debian Security Tracker — CVE-2026-13321
- SecurityWeek — BIND Updates Patch High-Severity Vulnerabilities
- TechGines — BIND 9 DNSSEC Vulnerability Puts Global DNS Resolver Infrastructure at Risk
- ISC BIND 9 DNSSEC Guide (stable)
- Cloudflare — DNSSEC Complexities and Considerations
- CVE Details — ISC BIND vulnerability list
- arXiv 2403.15233 — DNSSEC denial-of-existence CPU exhaustion research (context)
What defenders are saying.
Crowdsourced verification outputs.
Results submitted by users who ran the verification payload against their environment.