CVE-2026-44621 in Unbound
Summary
by MITRE • 07/22/2026
With NLnet Labs Unbound up to and including version 1.25.1, applications using libunbound and configured with 'unwanted-reply-threshold', could eventually be abruptly terminated if the threshold is reached and libunbound needs to call 'libworker_alloc_cleanup' since the function is absent from the function call allow list. When an application using libunbound sets 'unwanted-reply-threshold' to any non-zero value and the iterator queries an authoritative that replies with enough wrong-transaction-ID UDP datagrams to cross the threshold, the 'libworker_alloc_cleanup' will eventually be called. Since the function is absent from the function call allow list, this leads to a fatal exit of libunbound and eventual termination of the embedding application.Unbound itself is not affected since its relevant function 'worker_alloc_cleanup' is registed in the allow list and proceeds to perform the documented cache flush.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 07/22/2026
This vulnerability exists within NLnet Labs Unbound version 1.25.1 and earlier, specifically affecting applications that utilize the libunbound library with the 'unwanted-reply-threshold' configuration parameter. The flaw stems from an incomplete function call allow list implementation where the 'libworker_alloc_cleanup' function is missing from the permitted calls, creating a critical execution path that leads to abrupt application termination. When applications configure libunbound with any non-zero value for 'unwanted-reply-threshold', they establish a condition where iterator queries can trigger the threshold crossing mechanism. This occurs when authoritative servers respond with UDP datagrams containing incorrect transaction IDs, causing the system to accumulate enough violations to trigger the threshold limit.
The technical implementation issue manifests when the system reaches the configured threshold and attempts to invoke 'libworker_alloc_cleanup' for memory management purposes. However, since this function is not included in the function call allow list, the system cannot execute it properly and instead terminates the entire libunbound library process. This creates a denial of service condition that propagates to the embedding application, causing unexpected termination and potential service disruption. The vulnerability demonstrates a classic improper restriction of operations within allowed input vectors scenario, where an attacker can manipulate the system into calling unauthorized functions through legitimate configuration parameters.
The operational impact of this vulnerability extends beyond simple service interruption, as it affects any application relying on libunbound for DNS resolution services. Applications that configure 'unwanted-reply-threshold' to detect and mitigate certain types of DNS attacks or anomalies become particularly vulnerable when encountering malicious authoritative servers that deliberately send incorrect transaction ID responses. The vulnerability is classified under CWE-1226, which deals with improper restriction of operations within allowed input vectors, and aligns with ATT&CK technique T1499.004 for network denial of service attacks. Organizations using affected versions may experience unexpected application crashes during normal DNS query processing when encountering specific malicious responses.
Mitigation strategies focus on immediate version updates to Unbound 1.25.2 or later, which resolves the function call allow list issue by properly including 'libworker_alloc_cleanup' in the permitted operations. Additionally, administrators should consider implementing network-level protections such as DNS firewall rules that can detect and block excessive malformed UDP responses from known malicious sources. The recommended approach involves monitoring DNS query patterns to identify potential exploitation attempts and configuring applications to use more conservative threshold values while maintaining security effectiveness. Security teams should also implement proper application logging to track when 'unwanted-reply-threshold' is triggered, enabling rapid detection of potential exploitation attempts. Organizations may need to temporarily disable or restrict the use of 'unwanted-reply-threshold' until systems are updated to versions that properly handle this function call without causing application termination.