← Back to Feed CACHED · 2026-10-22 11:51:29 · CACHE_KEY CVE-2026-19630
CVE-2026-19630 · CWE-407 · Disclosed 2026-10-21

ISC BIND 9 resolver inbound DNS message name-compression resource exhaustion

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

Like mailing a letter that forces the post office to hand-copy every phone book in the building before it can deliver anyone else's mail

CVE-2026-19630 is an algorithmic complexity flaw (CWE-407) in ISC BIND 9's DNS message parser. When named receives a DNS message containing an excessive number of compressed name pointers, it expands every one of them without any imposed resource bound. A single crafted message can force the process to burn disproportionate CPU and memory expanding names, and a modest stream of such messages saturates all worker threads, causing legitimate DNS queries to time out. The affected range is enormous: BIND 9.11.0 through 9.18.50, 9.20.0 through 9.20.29, and 9.21.0 through 9.21.26 — essentially every BIND 9 release shipped in the past decade. Fixed versions are 9.20.30, 9.21.27, and 9.20.30-S1. No workaround exists; the fix adds a hard cap on per-message name expansion and returns FORMERR when the limit is exceeded.

ISC rates this HIGH at CVSS 7.5 and that assessment is accurate. The attack vector is network/unauthenticated/low-complexity/no-interaction — the worst possible access profile. The saving grace is that the impact ceiling is availability only: no code execution, no data leak, no persistence. ISC discovered the flaw internally and states it is aware of no active exploitation. Still, the asymmetric cost (attacker sends kilobytes, server burns CPU seconds) and the critical role of DNS resolvers in every enterprise make this a serious operational risk. For a fleet of 10,000 hosts, losing your primary DNS resolver means AD auth, email, web services, and basically every network-dependent process grinds to a halt until the attack stops or the service restarts.

"Vendor nailed it: unauthenticated DNS compression bomb takes out BIND resolvers with a whisper of traffic"
02 · The Attack Path

5 steps from start to impact.

STEP 01

Identify BIND resolver

The attacker locates a reachable BIND resolver. For internet-facing resolvers, tools like Shodan, Censys, or FOFA trivially enumerate targets — Censys has historically counted 700,000+ exposed BIND resolvers. For internal resolvers, the attacker needs prior network access (e.g., compromised VPN, phishing foothold, rogue insider). BIND's version is disclosed in version.bind CH TXT queries unless the operator has explicitly hidden it.
Conditions required:
  • Network path to UDP/53 or TCP/53 on the target resolver
Where this breaks in practice:
  • Internal-only resolvers require the attacker to already be inside the network
  • Operators who disable version.bind responses slow fingerprinting but don't block the attack
Detection/coverage: Shodan/Censys dorks for product:BIND on your external ranges. Internal asset inventory or dig version.bind CH TXT @<resolver> for self-audit.
STEP 02

Craft DNS message with excessive name compression

The attacker constructs a DNS message (query or synthesized packet) containing a large number of compressed domain-name pointers. DNS name compression (RFC 1035 §4.1.4) allows a 2-byte pointer to replace a name that appeared earlier in the message. By nesting or chaining many pointers, the attacker creates a message where named's expansion logic performs work exponential or polynomial in the message size. No special tooling beyond a raw socket and knowledge of the DNS wire format is required — a Python script using struct or scapy suffices.
Conditions required:
  • Knowledge of DNS wire format and compression pointer mechanics
  • Ability to craft and send raw DNS packets
Where this breaks in practice:
  • No public PoC exists as of 2026-10-22, raising the bar slightly for script kiddies
  • Constructing an optimal compression bomb requires understanding RFC 1035 pointer semantics
Detection/coverage: Deep packet inspection of DNS queries for anomalously high pointer-to-data ratios is theoretically possible but no vendor signature exists yet (CVE is <48 hours old).
STEP 03

Send crafted messages to target

The attacker transmits the crafted DNS messages to the resolver over UDP/53 (or TCP/53). The advisory and release notes confirm that minimal traffic is sufficient — a small number of packets per second can saturate all worker threads. Because DNS is connectionless over UDP, source-IP spoofing is trivial, making IP-based rate limiting less effective. The attack can be sustained from a single host or amplified via a small botnet.
Conditions required:
  • Ability to send UDP or TCP packets to port 53 on the target
Where this breaks in practice:
  • Egress filtering or BCP38 at the attacker's ISP limits spoofed-source attacks
  • DNS firewalls or upstream rate limiters may drop traffic above threshold, though the threshold for this attack is low
Detection/coverage: Anomalous CPU or query-latency spikes on the resolver. rndc status showing all workers busy. Prometheus/Grafana alerting on named process CPU utilization.
STEP 04

Worker thread saturation and service degradation

Each crafted message forces named to spend excessive CPU cycles expanding compressed names. With all worker threads tied up processing attacker messages, legitimate DNS queries queue and ultimately time out. The resolver effectively becomes unresponsive. The ISC release notes describe this as 'a client can saturate all worker threads with minimal traffic and time out legitimate queries.' Memory consumption also grows, potentially triggering OOM conditions.
Conditions required:
  • Steps 1-3 completed successfully
Where this breaks in practice:
  • Operators with multiple redundant resolvers (e.g., BIND + Unbound) maintain partial service
  • Automatic process restart (systemd watchdog) limits outage duration but doesn't prevent repeated attacks
Detection/coverage: named CPU at 100%, query response latency exceeding SLA, SERVFAIL rates spiking. SIEM correlation of DNS timeout events across clients.
STEP 05

Cascading service outage

With the DNS resolver down, all services depending on name resolution fail: Active Directory authentication, email delivery, web application backends, API calls to external services, certificate validation (OCSP/CRL), and monitoring systems that rely on DNS. In a 10,000-host enterprise, this is a fleet-wide availability event that persists as long as the attacker sustains traffic. Recovery requires restarting named (which the attacker can immediately re-saturate) or deploying the patch.
Conditions required:
  • No alternative DNS resolver available to clients
Where this breaks in practice:
  • Environments with diverse DNS infrastructure (e.g., secondary Unbound or cloud DNS) survive
  • Client-side DNS caching (TTLs) provides a brief grace period
Detection/coverage: Enterprise-wide service health dashboards showing correlated failures across unrelated applications — the hallmark of a DNS outage.
03 · Compensating Control

1
HIGH 7.5→MEDIUM 5.3
SEVERITY REDUCED
Restrict recursive resolver access to trusted networks only — Configure BIND's allow-recursion and allow-query ACLs to accept queries only from known internal subnets. Pair with firewall rules blocking port 53 from untrusted sources. This eliminates the unauthenticated-remote vector from the internet, leaving only internal attackers (who already have network access) as a threat. Deploy within 30 days per the noisgate mitigation SLA for HIGH-severity findings. This is the single most impactful control if your resolver is currently internet-facing.
2
HIGH 7.5→MEDIUM 4.5
SEVERITY REDUCED
Deploy diverse DNS resolver infrastructure — Add a non-BIND resolver (Unbound, PowerDNS Recursor, or cloud DNS like Cloudflare Gateway / Google Public DNS) as a secondary. Configure clients via DHCP to use both resolvers. If BIND is DoS'd, clients fail over to the unaffected resolver. This doesn't prevent the attack but eliminates the fleet-wide cascading failure. Implement within 30 days.
3
HIGH 7.5→HIGH 6.5
Apply per-source-IP query rate limiting at the network layer — Use iptables/nftables rate limiting on UDP/53 (e.g., --hashlimit 50/sec --hashlimit-burst 100) to cap query volume per source. This raises the bar for a single-source attacker, though distributed or spoofed-source attacks can bypass it. Deploy immediately as a stopgap.
4
HIGH 7.5→HIGH 6.0
Enable systemd watchdog restart for named — Configure WatchdogSec= and Restart=on-failure in the named.service unit file to auto-restart the process if it becomes unresponsive. This limits outage duration per attack burst to seconds rather than until manual intervention, though the attacker can re-trigger immediately. A band-aid, not a fix.
5
HIGH 7.5→IGNORE 0.0
SEVERITY REDUCED
Patch to BIND 9.20.30 / 9.21.27 — The only complete remediation. The fix adds a hard cap on per-message name expansion; messages exceeding it get FORMERR. ISC confirms ordinary traffic including zone transfers stays well within the limit. Apply within the 180-day noisgate remediation SLA for HIGH severity. If you are on 9.18.x or earlier, this requires a branch migration — plan accordingly.
What doesn't work
  • DNSSEC validation — DNSSEC validates response authenticity between authoritative servers and resolvers. It does not affect how named parses inbound message compression pointers. A DNSSEC-enabled resolver is equally vulnerable.
  • Web Application Firewall (WAF) — WAFs inspect HTTP/HTTPS traffic, not DNS wire protocol on port 53. Completely irrelevant.
  • DNS-over-HTTPS/TLS (DoH/DoT) — Changing the transport layer does not alter the DNS message wire format. The compression bomb payload is identical whether delivered over UDP, TCP, TLS, or HTTPS.
  • Response Rate Limiting (RRL) — BIND's built-in RRL throttles *outbound* responses to mitigate reflection/amplification attacks. It does not limit the CPU cost of *parsing inbound* messages, which is where this vulnerability lives.
04 · Intelligence Metadata

The supporting signals.

In-the-wild exploitationNone observed. ISC states the flaw was discovered through internal testing and is not aware of active exploits. Not listed in CISA KEV. No GreyNoise or Shadowserver scanning activity reported as of 2026-10-22.
Proof-of-concept availabilityNo public PoC. Checked pocindex.io, GitHub (CVE-2026-19630), ExploitDB, and Nuclei templates — no results. The flaw is straightforward to reproduce given RFC 1035 compression pointer knowledge, so a PoC is likely weeks away, not months.
EPSS scoreNot yet scored. FIRST EPSS API returns no data (CVE disclosed <48 hours ago). Historical BIND DoS CVEs typically land in the 5–15% EPSS range within 30 days.
CISA KEV statusNot listed. No known exploitation in the wild; KEV addition is unlikely absent active campaigns.
CVSS vectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H — Network-reachable, no auth, no complexity, no user interaction. Availability-only impact. This is the highest-risk access profile for a DoS flaw.
Affected versionsBIND 9.11.0–9.18.50, 9.20.0–9.20.29, 9.21.0–9.21.26. Preview Edition: 9.11.3-S1–9.18.50-S1, 9.20.9-S1–9.20.29-S1. The 9.18 branch is EOL — no fix will be issued; migration to 9.20.30+ is required.
Fixed versionsISC: 9.20.30, 9.21.27, 9.20.30-S1. Debian: 1:9.20.30-1~deb13u1. RHEL 9: RHSA-2026:75767. Ubuntu/SUSE advisories expected imminently.
Internet exposureCensys has historically counted 706,000+ internet-facing BIND 9 resolvers. Not all are vulnerable to this specific CVE (version-dependent), but the attack surface is massive. Many enterprises also run BIND as internal-only resolvers behind firewalls.
Disclosure timelineDisclosed 2026-10-21 by ISC alongside three other BIND 9 flaws (CVE-2026-94300 GSS-TSIG memory corruption at CVSS 8.1, CVE-2026-97313 dual-RPZ crash, CVE-2026-96888 redirect zone assertion failure).
Discovery creditDiscovered by ISC internal testing. No external researcher credited.

Sources.

  1. ISC Advisory — CVE-2026-19630
  2. BIND 9.21.27 Release Notes
  3. Security Online — ISC Patches Four BIND 9 Flaws
  4. Canadian Centre for Cyber Security — AV26-1072
  5. Red Hat RHSA-2026:75767
  6. CVEFeed — CVE-2026-19630 Detail
  7. Cyberpress — 706K BIND Resolvers Exposed (Censys)
05 · The Call

Final Verdict
= UNCHANGED to HIGH (7.5/10)

Why this verdict

  • Unauthenticated remote with zero complexity — The CVSS access vector (AV:N/AC:L/PR:N/UI:N) is the worst possible for a DoS. Any host that can reach port 53 can fire the attack. No downward adjustment warranted on access friction.
  • Asymmetric amplification makes this operationally dangerous — The release notes confirm 'a client can saturate all worker threads with minimal traffic.' This is not a volumetric flood requiring botnet-scale bandwidth; a single attacker with a home connection can take down a production resolver. This keeps the score firmly at the HIGH baseline.
  • Role multiplier: DNS resolvers are fleet-scale availability infrastructure — BIND resolvers sit in the (c) high-value role for virtually every enterprise deployment. A successful DoS against the primary resolver causes cascading failure across AD auth, email, monitoring, and all network-dependent services for the entire host fleet. The blast radius is fleet-scale availability disruption. However, the outcome is *disruption*, not *compromise* — no code execution, no data exfiltration, no domain takeover. This means the HIGH floor from the role analysis applies (fleet-scale impact on a canonical infrastructure component) but not the CRITICAL floor (which requires compromise-class outcomes).
  • No exploitation activity provides a small urgency offset — ISC found this internally, no PoCs exist, no KEV listing, no scanning observed. This doesn't reduce the *severity* but tempers the *urgency* relative to an actively exploited HIGH.
  • Enormous version range amplifies reach — Every BIND 9 release from 9.11.0 onward (roughly 2017–present) is affected. There is no configuration that disables the vulnerable code path and no workaround short of patching. This breadth prevents any downward adjustment for limited exposure.

Why not higher?

CRITICAL requires a path to confidentiality or integrity compromise, or an availability impact so severe it equates to safety risk (OT/ICS). This CVE's impact ceiling is A:H with C:N/I:N — it's a service disruption that ends when the attack stops or the process restarts. There is no code execution, no memory corruption leading to RCE, no data exposure. The concurrent CVE-2026-94300 (GSS-TSIG memory corruption, CVSS 8.1) in the same patch batch is closer to CRITICAL territory; this one is not.

Why not lower?

The attack is trivially weaponizable once a PoC emerges: craft a DNS message with chained compression pointers, send it to any reachable BIND resolver, and the server chokes. No authentication, no user interaction, low complexity, asymmetric cost, and BIND is the most widely deployed DNS server on the internet with 700K+ exposed instances. DNS is a single-point-of-failure for virtually every enterprise service. Dropping to MEDIUM would require either significant access friction (there is none for public resolvers) or a narrow affected population (the opposite is true).

06 · Verification

Crowdsourced verification payload.

Run this script on each host running BIND (named). No root required — it calls named -v which is world-executable. Example: chmod +x check_cve_2026_19630.sh && ./check_cve_2026_19630.sh. Exit code 0 = PATCHED, 1 = VULNERABLE, 2 = UNKNOWN.

noisgate-verify.sh
BASHREAD-ONLYSAFE
#!/usr/bin/env bash
# CVE-2026-19630 — ISC BIND name-compression resource exhaustion
# Checks installed BIND version against fixed releases.
# Exit: 0=PATCHED  1=VULNERABLE  2=UNKNOWN
set -uo pipefail

if ! command -v named &>/dev/null; then
  echo "UNKNOWN — 'named' not found in PATH; BIND may not be installed."
  exit 2
fi

RAW=$(named -v 2>&1 || true)
# Strip Preview Edition -S suffix for version comparison
CLEAN=$(echo "$RAW" | sed 's/-S[0-9]*//')
VER=$(echo "$CLEAN" | grep -oP '\d+\.\d+\.\d+' | head -1)

if [[ -z "$VER" ]]; then
  echo "UNKNOWN — could not parse BIND version from: $RAW"
  exit 2
fi

IFS='.' read -r MAJOR MINOR PATCH <<< "$VER"
echo "Detected: $RAW  (parsed: $MAJOR.$MINOR.$PATCH)"

if [[ "$MAJOR" -ne 9 ]]; then
  echo "UNKNOWN — not BIND 9 (major=$MAJOR). Check ISC advisory manually."
  exit 2
fi

if [[ "$MINOR" -ge 11 && "$MINOR" -le 18 ]]; then
  echo "VULNERABLE — BIND 9.${MINOR}.${PATCH} is in the 9.11-9.18 range (EOL, no fix). Migrate to >=9.20.30."
  exit 1
elif [[ "$MINOR" -eq 19 ]]; then
  echo "VULNERABLE — BIND 9.19.x dev branch predates fixed 9.20. Upgrade to >=9.20.30."
  exit 1
elif [[ "$MINOR" -eq 20 ]]; then
  if [[ "$PATCH" -ge 30 ]]; then
    echo "PATCHED — BIND 9.20.${PATCH} >= 9.20.30."
    exit 0
  else
    echo "VULNERABLE — BIND 9.20.${PATCH} < 9.20.30."
    exit 1
  fi
elif [[ "$MINOR" -eq 21 ]]; then
  if [[ "$PATCH" -ge 27 ]]; then
    echo "PATCHED — BIND 9.21.${PATCH} >= 9.21.27."
    exit 0
  else
    echo "VULNERABLE — BIND 9.21.${PATCH} < 9.21.27."
    exit 1
  fi
elif [[ "$MINOR" -lt 11 ]]; then
  echo "PATCHED — BIND 9.${MINOR}.x is below the affected range (starts at 9.11.0)."
  exit 0
else
  # 9.22+ or future branches
  echo "UNKNOWN — BIND 9.${MINOR}.x not in advisory scope. Consult ISC KB."
  exit 2
fi