In NLnet Labs Unbound up to and including 1.26.0

CVE-2026-81642 is a heap-based buffer overflow (CWE-122) in NLnet Labs Unbound versions up to and including 1.26.0. The flaw lives in the DNSSEC validation path: when Unbound digests a DNSKEY record whose owner name uses a compression pointer back into its own RDATA, the decompressed name is written past the end of the digest buffer. Because the overflowed data is attacker-controlled (it comes from the crafted DNSKEY), this yields reliable denial of service and *possible* remote code execution. The trigger is trivial — any client behind the resolver merely needs to look up a name in an attacker-controlled zone (click a link, load a tracking pixel, receive an email). DNSSEC validation is enabled by default in Unbound.

There is no vendor CVSS 3.1 baseline; the CVSS 4.0 score published alongside the advisory is 9.1 Critical. That score is defensible. The attack is unauthenticated, network-reachable, requires no user interaction on the resolver itself, and the only prerequisite — getting Unbound to query an attacker-controlled zone — is trivially satisfied in any enterprise that allows outbound web or email. The 'possible RCE' qualifier in the advisory reflects honest uncertainty about heap layout and compilation hardening (ASLR, stack canaries), not a fundamental barrier; heap overflows in C-based resolvers have been weaponized repeatedly (see: CVE-2020-8617, CVE-2015-7547). The reliable DoS impact alone is severe for a DNS resolver serving thousands of hosts.

Why this verdict

• Unauthenticated, zero-interaction trigger: The attacker never touches the resolver directly. Any DNS lookup to an attacker-controlled zone — triggered via email, web, chat, or even DNS prefetch — is sufficient. This is the lowest-friction remote trigger possible.
• DNSSEC validation is on by default: The vulnerable code path is exercised in the default Unbound configuration. Administrators who disabled DNSSEC validation are not affected, but this is rare in production deployments that chose Unbound specifically for its validation capabilities.
• Heap overflow with attacker-controlled data: CWE-122 in a C-based network daemon with attacker-controlled overflow content is the textbook precondition for RCE. The vendor's 'possible RCE' language reflects honest hedging, not a fundamental barrier.
• Role multiplier: Unbound is canonically a high-value network infrastructure component. ≥95% of Unbound installations serve as the recursive resolver for a network segment (enterprise LAN, ISP, cloud VPC). Compromise means: (a) DoS → all DNS-dependent services fail (authentication, web, email, updates, EDR telemetry); (b) RCE → attacker controls name resolution and can redirect any domain to attacker infrastructure, enabling credential theft, MITM, and supply-chain attacks via poisoned update URLs. The blast radius is fleet-scale by definition. This sets the verdict floor at CRITICAL.
• Nine-CVE batch release signals deep audit surface: The 1.26.1 release fixes 9 CVEs simultaneously, including use-after-free and heap corruption bugs. This suggests the codebase was under intensive scrutiny, and the attack surface may be broader than any single CVE.

Why not higher?

This is already assessed at CRITICAL (9.0). A 10.0 would require demonstrated wormable exploitation or active mass exploitation. Neither condition is met: no public PoC exists, no ITW exploitation is observed, and RCE reliability depends on compilation and runtime hardening. The 0.1-point reduction from the vendor's 9.1 CVSS 4.0 score reflects the RCE uncertainty.

Why not lower?

Downgrading below CRITICAL would require evidence that the attack path has meaningful friction or that Unbound is not canonically infrastructure. Neither is true. The trigger requires zero authentication and zero direct access to the resolver — just one DNS lookup from any client. DNSSEC validation is the default. Unbound IS the resolver by definition; ≥95% of installs occupy the high-value role. DoS alone on a network's DNS resolver is a HIGH-floor event; the credible RCE potential on a trust-critical service pushes through to CRITICAL.

1. Deploy DNS RPZ with domain-age and threat-intel blocklists — Block resolution of domains registered within the last 30 days or flagged by threat feeds. This raises the bar for the attacker to use an aged, clean domain. Deploy within 3 days per the noisgate mitigation SLA for CRITICAL findings.
2. Enable Unbound access-control to restrict query sources — Ensure access-control directives limit recursive queries to known internal subnets only. While this doesn't prevent the attack (internal clients are the trigger), it reduces exposure if the resolver is inadvertently internet-facing. Deploy within 3 days.
3. Run Unbound under systemd hardening (seccomp, chroot, PrivateNetwork) — Apply ProtectSystem=strict, PrivateDevices=yes, NoNewPrivileges=yes, and SystemCallFilter=~@privileged in the systemd unit. This limits post-exploitation capability if RCE is achieved. Deploy within 3 days.
4. Monitor resolver health with sub-minute polling — Configure Nagios, Zabbix, or Prometheus blackbox-exporter to query the resolver every 15 seconds. Automated restart via systemd is not sufficient — an attacker can crash faster than rate-limited restarts recover. Alert on consecutive failures.
5. Prepare fallback resolver — Ensure clients have a secondary DNS resolver (e.g., a separate Unbound instance on a different host, or a cloud resolver like 1.1.1.1/8.8.8.8 as tertiary) to maintain resolution during a DoS attack on the primary.

Run this script on each host running Unbound as any user with read access to the Unbound binary (typically root or the unbound service account). Invoke with: sudo bash check_cve_2026_81642.sh. No arguments required. The script checks the installed Unbound version against the fixed version (1.26.1).

#!/usr/bin/env bash
# check_cve_2026_81642.sh — Detect CVE-2026-81642 (Unbound DNSKEY digest heap overflow)
# Exit codes: 0 = PATCHED, 1 = VULNERABLE, 2 = UNKNOWN

set -euo pipefail

FIXED_MAJOR=1
FIXED_MINOR=26
FIXED_PATCH=1

# Locate unbound binary
UNBOUND_BIN=$(command -v unbound 2>/dev/null || echo "")
if [[ -z "$UNBOUND_BIN" ]]; then
  # Try common paths
  for p in /usr/sbin/unbound /usr/local/sbin/unbound /usr/bin/unbound; do
    [[ -x "$p" ]] && UNBOUND_BIN="$p" && break
  done
fi

if [[ -z "$UNBOUND_BIN" ]]; then
  echo "UNKNOWN — Unbound binary not found on this host."
  exit 2
fi

# Extract version
VERSION_OUTPUT=$($UNBOUND_BIN -V 2>&1 | head -1)
VERSION=$(echo "$VERSION_OUTPUT" | grep -oP '\d+\.\d+\.\d+' | head -1)

if [[ -z "$VERSION" ]]; then
  echo "UNKNOWN — Could not parse Unbound version from: $VERSION_OUTPUT"
  exit 2
fi

IFS='.' read -r MAJ MIN PAT <<< "$VERSION"

echo "Detected Unbound version: $VERSION (binary: $UNBOUND_BIN)"
echo "Fixed in: ${FIXED_MAJOR}.${FIXED_MINOR}.${FIXED_PATCH}"

# Compare versions
if (( MAJ > FIXED_MAJOR )) || \
   (( MAJ == FIXED_MAJOR && MIN > FIXED_MINOR )) || \
   (( MAJ == FIXED_MAJOR && MIN == FIXED_MINOR && PAT >= FIXED_PATCH )); then
  echo "PATCHED — Unbound $VERSION is >= ${FIXED_MAJOR}.${FIXED_MINOR}.${FIXED_PATCH}. CVE-2026-81642 is fixed."
  exit 0
else
  echo "VULNERABLE — Unbound $VERSION is < ${FIXED_MAJOR}.${FIXED_MINOR}.${FIXED_PATCH}. CVE-2026-81642 applies."
  # Also check if DNSSEC validation is enabled
  CONF=$(unbound-checkconf -o module-config 2>/dev/null || echo "unknown")
  if echo "$CONF" | grep -q "validator"; then
    echo "  DNSSEC validation is ENABLED (default) — vulnerable code path is active."
  elif [[ "$CONF" == "unknown" ]]; then
    echo "  Could not determine DNSSEC validation status. Assume vulnerable."
  else
    echo "  DNSSEC validation appears DISABLED — vulnerable code path may not be exercised."
  fi
  exit 1
fi

Sources

1. NLnet Labs Unbound Security Advisories
2. CVE-2026-81642 Detail — CVE Feed
3. Unbound 1.26.1 Release — GitHub
4. CVE-2026-81642 Analysis — Strix AI
5. Unbound DNSKEY Digest Overflow Analysis — HOL Blog
6. NLnet Labs CVE-2026-81642 Advisory Text
7. DNS Server Market Share Statistics