CVE-2026-73206 · PowerDNS Recursor DNS name decompression resource exhaustion denial…

01 · The Real Story

A zip bomb hidden inside a DNS reply that chokes your resolver like a clogged pipe

CVE-2026-73206 is a denial-of-service vulnerability in PowerDNS Recursor (versions through 5.3.11 and through 5.4.7) caused by unbounded work during DNS name decompression. A malicious authoritative DNS server can return a crafted reply with deeply chained or looping name-compression pointers. When the Recursor processes this reply, it consumes excessive CPU and memory attempting to decompress the name labels, stalling or crashing the resolver process. The attack is unauthenticated, network-reachable, and low-complexity — the attacker only needs to control a domain's authoritative nameserver and trick (or wait for) the target Recursor to resolve a name in that zone. The fix in versions 5.3.12 and 5.4.8 caps decompression work both per-name and per-packet. This is a multi-vendor issue: the same Tsinghua/SJTU research team disclosed similar decompression flaws in other DNS implementations (e.g., CVE-2026-96405 for Unbound).

PowerDNS rates this High with CVSS 7.5, and that call is defensible. The vector — AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H — correctly captures that any network-reachable Recursor is trivially targetable with no auth and no user interaction. The ceiling is capped at availability-only impact (no code execution, no data leak), which prevents it from crossing into CRITICAL territory. However, DNS resolution is foundational infrastructure: when your Recursor goes down, every service that depends on name resolution — authentication, email, web apps, API calls — degrades or fails. For ISPs running PowerDNS Recursor for millions of subscribers, or enterprises using it as their internal caching resolver, this is not a minor outage. The vendor's HIGH rating is appropriate.

"Unauthenticated DNS decompression bomb crashes PowerDNS Recursor — patch DNS infra now"

02 · The Attack Path

4 steps from start to impact.

STEP 01

Attacker registers domain and sets up malicious authoritative NS

The attacker registers any domain (e.g., evil.example) and configures an authoritative nameserver they control. This nameserver is programmed to return crafted DNS replies containing deeply nested or circular name-compression pointers in the answer, authority, or additional sections. No special access to the target environment is needed at this stage.

Conditions required:

Ability to register a domain and run an authoritative DNS server

Where this breaks in practice:

Trivial — domain registration costs pennies and open-source DNS server software is free

STEP 02

Trigger recursive resolution of attacker-controlled domain

The attacker needs the target PowerDNS Recursor to query their malicious authoritative server. This happens when any client behind the Recursor resolves a name under the attacker's domain. The attacker can trigger this by sending a direct DNS query to the Recursor (if reachable), embedding a resource reference (image, CSS, JS) in a web page or email, or exploiting any application that performs DNS lookups on attacker-supplied input. For open resolvers, the attacker can query directly from the internet.

Conditions required:

Target Recursor is reachable by the attacker directly, or a client behind the Recursor can be induced to resolve the attacker's domain

Where this breaks in practice:

Well-configured Recursors restrict query sources via ACL (allow-from), limiting direct access to internal clients only
The attacker still needs a way to trigger a lookup — phishing, watering-hole, or any web content with an embedded external resource suffices

Detection/coverage: Query logging on the Recursor may show unusual query patterns to previously unseen domains; DNS firewall / RPZ policies can block known-bad domains

STEP 03

Malicious reply triggers unbounded decompression

The Recursor sends a recursive query to the attacker's authoritative server. The server responds with a packet containing name-compression pointers designed to cause exponential or excessive decompression work. The unpatched Recursor follows these pointers without limits, consuming CPU cycles and memory proportional to the depth/branching of the pointer chains. A single crafted reply can cause significant resource exhaustion.

Conditions required:

Target runs PowerDNS Recursor ≤ 5.3.11 or ≤ 5.4.7 (unpatched)

Where this breaks in practice:

The attack payload is in the DNS reply, not the query — network-level packet inspection of DNS responses is uncommon
Response Policy Zones (RPZ) and DNS firewalls operate on domain names, not on packet-level compression — they won't catch this

Detection/coverage: Abnormal CPU/memory spikes on the Recursor host; process monitoring (e.g., Prometheus pdns_recursor metrics) showing elevated servfail rates or latency; no known IDS/IPS signature as of disclosure date (Oct 21, 2026)

STEP 04

Resolver denial of service achieved

The Recursor process becomes unresponsive or crashes due to resource exhaustion. All DNS resolution for clients relying on this Recursor fails. Depending on client retry behavior and the presence of secondary resolvers, the impact ranges from seconds of degraded resolution to sustained outage. The attacker can repeat the attack at will by sending additional queries, making recovery without patching unreliable.

Conditions required:

Steps 1-3 completed successfully

Where this breaks in practice:

High-availability DNS deployments with multiple independent Recursor instances limit blast radius — the attacker must target each instance separately
Anycast DNS deployments may route queries to different backends, requiring broader targeting
Watchdog/systemd auto-restart of the Recursor process may provide partial recovery between attack waves

Detection/coverage: DNS monitoring dashboards (Grafana + Prometheus with pdns_recursor exporter) will show query failure spikes; client-side monitoring (e.g., Catchpoint, ThousandEyes) will flag DNS resolution failures

03 · Compensating Control

HIGH 7.5→MEDIUM 5.5

SEVERITY REDUCED

Deploy redundant Recursor instances behind health-checked load balancing — Run at least two independent PowerDNS Recursor instances (ideally on separate hosts) behind a health-checking load balancer or use systemd watchdog with automatic restart. If one instance is DoS'd, queries failover to the surviving instance. This limits the blast radius from site-wide outage to temporary degradation. Per the noisgate mitigation SLA for HIGH, deploy within 30 days.

HIGH 7.5→MEDIUM 5.9

SEVERITY REDUCED

Restrict query sources via allow-from ACL — Ensure the Recursor's allow-from setting restricts queries to known internal subnets only. This prevents direct internet-based exploitation by external attackers, forcing them to use indirect trigger methods (inducing internal clients to resolve attacker domains). Per the noisgate mitigation SLA for HIGH, verify ACL configuration within 30 days.

HIGH 7.5→HIGH 6.5

Deploy DNS Response Policy Zones (RPZ) with threat intel feeds — Use RPZ to block resolution of known-malicious domains. While RPZ cannot detect the compression-pointer payload itself, it can block the attacker's domain before the recursive query ever reaches the malicious authoritative server. Feed RPZ with threat intelligence from providers like Farsight DNSDB, Spamhaus, or commercial feeds. This is a probabilistic control — it only helps if the attacker's domain is already flagged.

HIGH 7.5→IGNORE 0.0

SEVERITY REDUCED

Apply vendor patch (5.3.12 or 5.4.8) — The definitive fix. Versions 5.3.12 and 5.4.8 cap decompression work per-name and per-packet, eliminating the resource exhaustion vector entirely. Per the noisgate remediation SLA for HIGH, apply the patch within 180 days. Given the low complexity of reproduction, front-loading this patch is strongly recommended.

What doesn't work

Upstream firewall rate-limiting DNS traffic — The attack payload is in the *reply* from the malicious authoritative server, not in the client query. Rate-limiting inbound queries does not prevent the Recursor from sending outbound recursive queries and receiving the malicious reply. You'd need to rate-limit or inspect outbound DNS, which breaks normal resolution.
DNSSEC validation — DNSSEC validates the authenticity and integrity of DNS data but does not inspect or limit name-compression pointer depth. A DNSSEC-signed malicious zone with compression bombs would pass validation and still trigger the DoS.
Switching to DNS-over-HTTPS (DoH) or DNS-over-TLS (DoT) for clients — These encrypt the client-to-resolver leg but do not affect the resolver-to-authoritative leg where the malicious reply is delivered. The compression bomb arrives via standard DNS protocol between the Recursor and the attacker's authoritative server.

04 · Intelligence Metadata

The supporting signals.

In-the-Wild Exploitation	No known exploitation. Not listed in CISA KEV. Disclosed October 21, 2026 — only 2 days old at time of assessment. No campaigns or threat actor activity reported.
Proof-of-Concept Availability	No public PoC found. Checked pocindex.io, GitHub, ExploitDB — no repositories or exploit code for CVE-2026-73206. The research team (Tsinghua/SJTU) has not published exploit code. However, crafting a malicious DNS reply with decompression loops is straightforward for anyone with DNS protocol knowledge.
EPSS Score	Not yet scored. CVE was published October 21, 2026; EPSS scores typically propagate within 1-2 weeks of NVD publication. Expect low-to-moderate EPSS given DoS-only impact class.
CVSS Vector	`CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H` — 7.5 HIGH. Network-accessible, zero-click, no auth. Scope unchanged (only the Recursor process is directly affected, though cascading DNS failures are wide-reaching).
Affected Versions	PowerDNS Recursor ≤ 5.3.11 (5.3.x branch) and ≤ 5.4.7 (5.4.x branch). Older unsupported branches (4.x, 5.0.x, 5.1.x, 5.2.x) likely affected but no backports announced.
Fixed Versions	PowerDNS Recursor 5.3.12 and 5.4.8, released October 21, 2026. Debian DSA-6397-1 issued. Check distro trackers for RHEL, Ubuntu, SUSE backport status.
Scanning / Exposure	PowerDNS Recursor powers 150M+ internet connections per vendor claims. Primarily deployed by ISPs, telecom operators, and enterprises as internal caching resolvers. Internet-facing open resolvers running PowerDNS are discoverable via Shodan (`product:"PowerDNS Recursor"`), though most enterprise deployments are internal-only.
Multi-Vendor Scope	The advisory notes this is a multi-vendor issue affecting multiple DNS providers. The same research team disclosed CVE-2026-96405 (Unbound decompression flaw). Coordinated disclosure across DNS implementations suggests a systemic protocol-level weakness in how resolvers handle RFC 1035 name compression.
Researchers	Yuheng Zhang (Tsinghua University), Zihan Zhang (Shanghai Jiao Tong University), Jianjun Chen, Zihan Wang (Z.AI Co.), Kaiwen Shen (CloudItera). This team has a strong track record in DNS security research (prior work on DNS cache boundary attacks, glue record handling).
Disclosure Timeline	Discovered July 10, 2026. Public disclosure October 21, 2026 (103-day coordinated disclosure). PowerDNS advisory 2026-12 (internal ID 537).

Sources.

05 · The Call

Final Verdict

= UNCHANGED to HIGH (7.5/10)

Why this verdict

Unauthenticated remote trigger with zero user interaction. The CVSS vector AV:N/AC:L/PR:N/UI:N is accurate — any entity that can send a DNS query to the Recursor (or induce a client to resolve an attacker-controlled domain) can trigger the flaw. There is no authentication barrier, no exploit chain complexity, and no social engineering required beyond a benign-looking DNS lookup.
DNS infrastructure occupies a foundational high-value role. PowerDNS Recursor serves as the DNS caching resolver for ISPs (150M+ connections) and enterprises. When a resolver goes down, the blast radius is not one application — it is every service, authentication flow, and API call that depends on name resolution. This is analogous to knocking out the switchboard, not just one phone line.
Role multiplier: DNS resolver (high-value infrastructure). In ISP deployments, the chain succeeds trivially (attacker queries open resolver → DoS). Blast radius: segment-wide to organization-wide DNS failure. In enterprise deployments with ACLs, the attacker must induce an internal client to resolve the malicious domain (lower friction than it sounds — an embedded image in an email or web page suffices). Blast radius: campus/site-wide DNS failure. ≥10% of PowerDNS Recursor installs are ISP-grade infrastructure where the resolver IS the high-value role. The floor is HIGH.
Multi-vendor research amplifies credibility. The same Tsinghua/SJTU team disclosed equivalent flaws in Unbound (CVE-2026-96405) and likely other implementations. This is not a one-off coding bug — it's a class of protocol-level decompression abuse that any competent attacker can reproduce once the advisory describes the fix (capping decompression work per-name and per-packet).
No PoC yet, but low barrier to reproduction. RFC 1035 name compression is well-documented. Constructing a reply with nested/looping pointers requires only scapy or a custom authoritative server. The 2-day window since disclosure limits current risk but the exploit complexity is objectively low.

Why not higher?

CRITICAL would require code execution, data compromise, or supply-chain impact. This vulnerability is availability-only — no confidentiality or integrity impact, no path to remote code execution, no persistence mechanism. The Recursor process crashes or stalls but does not yield a shell. While DNS outages are operationally severe, the CVSS scope is Unchanged (S:U) and the impact ceiling is firmly capped at denial of service. Additionally, well-architected DNS deployments with multiple independent resolver instances and health-check-based failover can contain the blast radius.

Why not lower?

MEDIUM would undervalue the combination of zero-auth remote reachability and foundational infrastructure impact. The attack requires no exploit chain, no privilege, and no user interaction beyond normal DNS resolution behavior. The trigger mechanism (embedding a resource reference to an attacker-controlled domain) is one of the lowest-friction initial vectors in the attacker playbook. DNS is not a peripheral service — it is a hard dependency for virtually every networked operation. Downgrading to MEDIUM would only be justified if the attack required local access or authenticated sessions, neither of which applies here.

06 · Verification

Crowdsourced verification payload.

Run this script on each host running PowerDNS Recursor as any user with read access to the pdns_recursor binary or package manager. Example: bash check_cve_2026_73206.sh. No root required unless the binary path is restricted.

noisgate-verify.sh

BASHREAD-ONLYSAFE

#!/usr/bin/env bash
# check_cve_2026_73206.sh — Detect CVE-2026-73206 in PowerDNS Recursor
# Tests whether the installed pdns-recursor version is vulnerable to
# DNS name decompression denial of service.
# Exit codes: 0 = PATCHED, 1 = VULNERABLE, 2 = UNKNOWN

set -euo pipefail

VULNERABLE_53="5.3.11"   # Last vulnerable in 5.3.x branch
VULNERABLE_54="5.4.7"    # Last vulnerable in 5.4.x branch
FIXED_53="5.3.12"
FIXED_54="5.4.8"

# Attempt to get version from rec_control, then binary, then package manager
get_version() {
  if command -v rec_control &>/dev/null; then
    rec_control version 2>/dev/null && return
  fi
  if command -v pdns_recursor &>/dev/null; then
    pdns_recursor --version 2>&1 | grep -oP '[0-9]+\.[0-9]+\.[0-9]+' | head -1 && return
  fi
  # Try package managers
  if command -v dpkg &>/dev/null; then
    dpkg -s pdns-recursor 2>/dev/null | grep '^Version:' | grep -oP '[0-9]+\.[0-9]+\.[0-9]+' | head -1 && return
  fi
  if command -v rpm &>/dev/null; then
    rpm -q pdns-recursor 2>/dev/null | grep -oP '[0-9]+\.[0-9]+\.[0-9]+' | head -1 && return
  fi
  echo ""
}

# Compare versions: returns 0 if $1 <= $2
version_lte() {
  [ "$(printf '%s\n%s' "$1" "$2" | sort -V | head -1)" = "$1" ]
}

VERSION=$(get_version)

if [ -z "$VERSION" ]; then
  echo "UNKNOWN — PowerDNS Recursor not found on this host"
  exit 2
fi

echo "Detected PowerDNS Recursor version: $VERSION"

# Determine branch and check
MAJOR_MINOR=$(echo "$VERSION" | grep -oP '^[0-9]+\.[0-9]+')

case "$MAJOR_MINOR" in
  5.4)
    if version_lte "$VERSION" "$VULNERABLE_54"; then
      echo "VULNERABLE — version $VERSION is <= $VULNERABLE_54 (fixed in $FIXED_54)"
      exit 1
    else
      echo "PATCHED — version $VERSION is >= $FIXED_54"
      exit 0
    fi
    ;;
  5.3)
    if version_lte "$VERSION" "$VULNERABLE_53"; then
      echo "VULNERABLE — version $VERSION is <= $VULNERABLE_53 (fixed in $FIXED_53)"
      exit 1
    else
      echo "PATCHED — version $VERSION is >= $FIXED_53"
      exit 0
    fi
    ;;
  5.2|5.1|5.0|4.*)
    echo "VULNERABLE — version $VERSION is on an unsupported branch with no patch available. Upgrade to 5.3.12+ or 5.4.8+."
    exit 1
    ;;
  *)
    if version_lte "$FIXED_54" "$VERSION"; then
      echo "PATCHED — version $VERSION is newer than all known vulnerable versions"
      exit 0
    fi
    echo "UNKNOWN — version $VERSION could not be mapped to a known branch. Verify manually."
    exit 2
    ;;
esac