Unbound libunbound CVE-2026-44621

Two explicit conditions must both be true. First, the target application must embed libunbound (not use standalone Unbound) and must set 'unwanted-reply-threshold' to any non-zero integer - this is not the default; an operator must have deliberately enabled it. Second, the attacker must control or be able to spoof UDP datagrams appearing to originate from an authoritative nameserver that the target resolver is actively querying, and must sustain this spoofing long enough to exceed the configured threshold. What limits exploitation: standalone Unbound is categorically unaffected; applications that never set 'unwanted-reply-threshold' are unaffected regardless of version; the AC:H CVSS rating reflects the real-world difficulty of controlling or spoofing authoritative DNS responses at sufficient volume; and the attacker must time the attack to coincide with active queries to a nameserver they influence.

The CVSS 3.1 score of 5.9 (Medium) with vector AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H reflects a purely availability-impacting flaw with elevated attack complexity. AC:H is well-justified: the attacker must control or convincingly spoof responses from an authoritative nameserver that the target resolver is querying - a non-trivial network positioning requirement. The impact is hard availability loss (A:H) against the embedding application, with no confidentiality or integrity exposure. No EPSS score was provided in the source data, and there is no CISA KEV listing, indicating no confirmed active exploitation at the time of this analysis. The vulnerability is further constrained by requiring a non-default, explicitly configured option ('unwanted-reply-threshold' set to any non-zero value); applications that never set this option are entirely unaffected. Standalone Unbound deployments are also categorically unaffected. The realistic risk is therefore moderate and bounded: the population of vulnerable targets is limited to applications embedding libunbound with this specific option enabled, and the exploit requires meaningful attacker control over DNS infrastructure. This is not a mass-exploitation scenario but remains a credible denial-of-service vector for targeted attacks against specific DNS-dependent applications.

An attacker who operates or has compromised an authoritative nameserver - or who is positioned to spoof UDP packets from one - waits for a target application embedding libunbound to query a domain they control. They respond with a sustained flood of UDP datagrams carrying wrong transaction IDs until the application's configured 'unwanted-reply-threshold' is crossed, causing libunbound to invoke its unregistered cleanup function and crash the embedding process. No public proof-of-concept code is known at this time, but the attack logic follows directly from the vendor's description and is straightforward for an attacker with appropriate DNS infrastructure.