NLnet Labs Unbound CVE-2026-46582

The serve-expired feature must be enabled in Unbound (configured via 'serve-expired: yes' in unbound.conf - this is not the default in all distributions but is commonly enabled for performance). The victim zone must contain a wildcard record and a sibling record that could be covered by that wildcard. The attacker must control at least one DNSSEC-signed domain (any domain suffices; it does not need to be related to the victim zone) and must be able to inject a crafted wildcard RRSET - without its accompanying NSEC record - into a DNS response that Unbound receives during the serve-expired refresh window. A thread-timing race must be won: the resolving thread must set the rrset to secure from RRSIG validation before the serve-expired thread reads it. What limits exploitation: the serve-expired code path requirement (non-default in many deployments), dependence on a specific wildcard-plus-sibling DNS zone structure in the victim domain, the need to win a thread race, and the attacker's dependency on influencing DNS responses Unbound receives (e.g., via a poisoned upstream or as the authoritative server for the injected records).

The NVD CVSS 3.1 score of 3.7 (AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:L/A:N) accurately reflects the constrained real-world impact. Attack complexity is genuinely High: exploitation requires the attacker to control any DNSSEC-signed domain, craft a CNAME wrapper pointing to a sibling of a wildcard in the victim zone, seed the Unbound cache through a specific query sequence, wait for expiry, and then win a thread race during serve-expired resolution - all coordinated precisely. The integrity impact is low and scoped to a single cache record rather than broad cache poisoning. No EPSS data was provided in the input; KEV status is absent, meaning CISA has not confirmed active exploitation. No public POC has been identified. The primary concern is for recursive resolver operators who serve DNSSEC-validating clients and have serve-expired enabled, because the poisoned entry carries a spuriously 'secure' DNSSEC status, which could suppress downstream validation errors in stub resolvers that trust the resolver's AD bit. The gap between CVSS network vector (AV:N) and the description's requirement for coordinated multi-step setup is consistent - the network vector refers to the delivery of the DNS queries, not a simple single-packet exploit. This is a genuine but low-priority finding absent signs of active exploitation.

An attacker who controls any DNSSEC-signed domain (unrelated to the victim) creates a CNAME record pointing to a sibling record of a wildcard in the victim zone, then queries the victim's Unbound resolver for the wildcard sibling to seed the cache with a transiently-secure wildcard RRSET. After the cache entry expires, the attacker queries the CNAME wrapper, causing Unbound to re-resolve via the serve-expired path; if the attacker can inject the wildcard RRSET (without NSEC records) into the upstream response during this window, the threading race causes the sibling record to be overwritten with the wildcard and marked DNSSEC-secure, returning a poisoned answer to downstream clients. No public POC exists at time of analysis, and the multi-step coordination required makes opportunistic exploitation unlikely.