← Back to Feed CACHED · 2026-07-23 02:31:32 · CACHE_KEY CVE-2026-13321
CVE-2026-13321 · CWE-346 · Disclosed 2026-07-22

The BIND resolver accepts validly-signed NSEC records where the "Next Domain Name" field points outside the…

ASSESSED — NOISGATE V0.5
Vendor
Reassessed
Verdict:
Do you agree?
01 · The Real Story

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.09.18.50, 9.20.09.20.24, 9.21.09.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.

"DNSSEC validation bypass on a canonical resolver — any signed zone owner can poison any cached name. Floor is CRITICAL."
02 · The Attack Path

5 steps from start to impact.

STEP 01

Attacker stands up a DNSSEC-signed authoritative zone they control

Register a cheap domain, host it on an authoritative nameserver the attacker owns, sign it with a valid DNSKEY chain reachable from the root. This is a Tuesday activity — ldns-signzone, dnssec-signzone, or Knot DNS all do it in one command. No exotic capability required.
Conditions required:
  • ability to register or lease a DNSSEC-enabled domain
  • any authoritative nameserver the attacker controls
Where this breaks in practice:
  • none — costs less than a coffee
Detection/coverage: Registrar-side abuse detection is essentially nil for newly-signed zones.
STEP 02

Craft an NSEC record whose Next Domain Name crosses into the victim zone

The attacker mints an NSEC covering, e.g., a.attacker.tldlogin.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.
Conditions required:
  • knowledge of a victim name to poison (public knowledge)
  • control of the signing keys for the attacker's zone
Where this breaks in practice:
  • requires the crafted NSEC to actually be queried and cached — see next step
Detection/coverage: No mainstream IDS rules distinguish an out-of-zone NSEC from a legitimate one at wire level.
STEP 03

Induce the victim resolver to query the attacker's zone

Trigger any client behind the target BIND resolver to look up a name under 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.
Conditions required:
  • 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)
Where this breaks in practice:
  • negligible — DNS lookups happen constantly and are trivial to induce
Detection/coverage: Passive DNS diffs would catch anomalous NXDOMAIN caching only after the fact.
STEP 04

Downstream clients receive the authenticated lie

Any client using the poisoned resolver now gets an AD=1 NXDOMAIN (or a lying NSEC-derived denial) for the targeted name — for the TTL window the attacker chose. Effects range from denying access to legitimate services (a targeted DoS via denial-of-existence) to breaking security-sensitive lookups: OCSP, CRL, CAA records, HSTS-preload probes, _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.
Conditions required:
  • poisoned entry lives in cache for the TTL
  • downstream application trusts DNS (essentially all of them do)
Where this breaks in practice:
  • scoped to what NSEC denial can express — this is integrity-of-denial, not arbitrary A-record injection; still enormous
Detection/coverage: Application-layer failures (mail rejections, TLS handshake anomalies) are the tell. No DNS-native alerting will fire.
STEP 05

Chain into higher-impact primitives

Coupled with cache-injection tricks or Kaminsky-style birthday attacks against non-DNSSEC glue, the authenticated NSEC becomes a lever for wider poisoning. Even standalone, sustained denial of _dmarc, _domainkey, and MTA-STS records for a target domain is a phishing enabler at fleet scale.
Conditions required:
  • patient attacker, long TTL, iterative poisoning of related names
Where this breaks in practice:
  • defenders using DoH/DoT egress to non-BIND upstreams (Google/Cloudflare/Quad9) sidestep this
Detection/coverage: Requires cross-correlating mail auth failures with resolver behavior — few SOCs do this.
03 · Intelligence Metadata

The supporting signals.

In-the-wild statusNo confirmed exploitation per ISC advisory as of 2026-07-22. Not KEV-listed.
PoC availabilityNo 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.
EPSSNew CVE — EPSS not yet meaningful; expect rapid climb given resolver-tier impact.
KEVNot listed (2026-07-23).
CVSS vectorCVSS: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 versionsBIND 9.11.09.18.50, 9.20.09.20.24, 9.21.09.21.23, 9.11.3-S19.18.50-S1, 9.20.9-S19.20.24-S1.
Fixed versionsBIND 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 dataShodan 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.
Disclosure2026-07-22 — ISC KB cve-2026-13321.
CreditQifan Zhang, Palo Alto Networks.
04 · The Call

noisgate verdict.

Final Verdict
UPGRADED to CRITICAL (9.3/10)

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.

HIGH vulnerability mechanism and affected version ranges
HIGH blast radius reasoning (resolver-tier bug)
MEDIUM exploitation timeline — no public PoC yet, but conceptually trivial

Why this verdict

  • Role multiplier — recursive resolver tier: BIND 9 with dnssec-validation is 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).

05 · Compensating Control

What to do — in priority order.

  1. 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.
  2. 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.
  3. Shorten resolver cache max-TTL to reduce poisoning dwell — Set max-cache-ttl 300 and max-ncache-ttl 300 in named.conf. Doesn't prevent poisoning but caps the damage window to 5 minutes per injection.
  4. 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.
  5. Add monitoring for anomalous NXDOMAIN spikes on security-critical names — Alert on unexpected NXDOMAIN for _dmarc.*, _mta-sts.*, caa queries, and OCSP hosts. This is the wire-level tell of an in-progress poisoning campaign.
What doesn't work
  • 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.
06 · Verification

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.

noisgate-verify.sh
BASHREAD-ONLYSAFE
#!/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
07 · Bottom Line

If you remember one thing.

TL;DR
Monday morning: inventory every BIND 9 recursive resolver (internal and edge) with 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

  1. ISC KB — CVE-2026-13321 advisory
  2. Debian Security Tracker — CVE-2026-13321
  3. SecurityWeek — BIND Updates Patch High-Severity Vulnerabilities
  4. TechGines — BIND 9 DNSSEC Vulnerability Puts Global DNS Resolver Infrastructure at Risk
  5. ISC BIND 9 DNSSEC Guide (stable)
  6. Cloudflare — DNSSEC Complexities and Considerations
  7. CVE Details — ISC BIND vulnerability list
  8. arXiv 2403.15233 — DNSSEC denial-of-existence CPU exhaustion research (context)
Peer Review

What defenders are saying.

Submit a review attribution: handle + country only
0 flags selected · stored anonymously
Validation Results

Crowdsourced verification outputs.

Results submitted by users who ran the verification payload against their environment.