NLnet Labs Unbound EUVD-2026-31087

Three specific conditions must ALL be present simultaneously for exploitation: (1) Unbound must be configured with 'num-threads' greater than 1 (multi-threaded mode); (2) at least one RPZ zone must be configured with 'rpz-nsip' or 'rpz-nsdname' trigger types - 'rpz-qname' or other trigger types alone do not expose the vulnerability; (3) that RPZ zone must be provisioned via remote XFR (zone transfer from a primary server), not a local file - the advisory explicitly states 'Local RPZ files do not trigger the vulnerability.' Exploitation is further gated by race condition timing: an XFR must be actively in progress at the precise moment another thread reads the RPZ zone, which limits reliable exploitation to scenarios where an attacker can influence or observe the XFR schedule. PR:N indicates no authentication is required to trigger the DNS query side of the race. Limiting factors include: the requirement for a non-default multi-threaded + RPZ-over-XFR deployment, the probabilistic nature of the race, and the absence of any scope impact beyond availability of the vulnerable Unbound instance itself.

The CVSS 4.0 score of 4.6 (Medium) reflects the genuine complexity of exploitation. The vector AV:N/AC:H/AT:P/PR:N/UI:N with VA:H captures the key tension: the impact is unambiguously high (full availability loss of the resolver), but AC:H (High Attack Complexity) and AT:P (Attack Requirements: Present) significantly constrain exploitability. Three conditions must simultaneously hold: Unbound must be running in multi-threaded mode, an RPZ zone with 'rpz-nsip' or 'rpz-nsdname' triggers must be configured, and an active XFR for that zone must be in progress at the moment of exploitation. Local RPZ file loading does not expose the race condition, further narrowing the attack surface. The exploit signal modifier E:U (Unreported/Unproven) and Amber urgency rating reinforce that no functional exploit code is known. EPSS data was not provided in source intelligence. KEV status is negative. The real-world risk is significant for authoritative-resolver operators relying on RPZ for security filtering with remote zone transfer feeds, but negligible for configurations using local RPZ files only. The race condition dependency means exploitation is probabilistic and may require repeated attempts, which may generate observable anomalous query patterns. This is not a high-priority emergency for most deployments, but patch urgency increases for RPZ-over-XFR users given the potential for denial-of-service to DNS infrastructure.

An adversary targeting an organization's recursive DNS resolver first identifies or infers that the resolver runs a multi-threaded Unbound instance with an RPZ zone using 'rpz-nsip' or 'rpz-nsdname' triggers provisioned via XFR. The attacker then monitors or coerces an XFR event - for example, by modifying the RPZ primary zone to trigger a notify/transfer - and simultaneously sends DNS queries that cause Unbound's RPZ evaluation thread to read the zone structure. If the race condition fires, the XFR thread frees RPZ objects mid-traversal by the reader, crashing the resolver process and causing a denial of service for all clients relying on that resolver. No public proof-of-concept code exists at time of analysis, but the race window is externally observable and could be reliably timed by an adversary with knowledge of the XFR schedule.