CVE-2026-56444 in Unbound
Summary
by MITRE • 07/22/2026
In NLnet Labs Unbound 1.20.0 up to and including 1.25.1, when Unbound is configured with 'serve-expired: yes' and 'serve-expired-client-timeout > discard-timeout > 0' (contrary to the suggested values), the discard-timeout branch during the serve expired logic drops an aged client reply without performing the correct accounting for the number of reply addresses for the query. Other identical branches outside of serve expired perform the correct decrement. Since the counter is never decremented in such scenario, it can reach the maximum limit and new clients for duplicate in-flight queries are silently dropped resulting in degradation of resolution service. A malicious actor can exploit the vulnerability by querying the resolver for a client-controlled slow-on-demand authoritative zone that can drive the counter past the threshold. Shipped defaults for 'serve-expired-client-timeout: 1800' and 'discard-timeout: 1900' make the branch unreachable.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 07/22/2026
This vulnerability exists in NLnet Labs Unbound DNS resolver versions 1.20.0 through 1.25.1 and represents a critical flaw in the serve expired functionality that can lead to service degradation and potential denial of service conditions. The issue manifests when the resolver is configured with specific parameter values that contradict the recommended defaults, creating an unintended code path that affects client reply accounting mechanisms. The vulnerability stems from improper handling of reply address counters within the discard-timeout branch during expired query processing, where the system fails to properly decrement the counter for aged client replies.
The technical flaw occurs specifically when 'serve-expired: yes' is enabled along with 'serve-expired-client-timeout > discard-timeout > 0', creating a scenario where the accounting logic for reply addresses becomes inconsistent. Within the serve expired processing path, the discard-timeout branch neglects to perform the correct decrement operation on the reply address counter, while all other similar branches outside the serve expired context properly maintain this accounting. This discrepancy results in a gradual accumulation of counter values that eventually reaches maximum limits, causing new client requests for duplicate in-flight queries to be silently dropped without any error indication.
The operational impact of this vulnerability extends beyond simple service degradation into potential complete resolution failure. As the reply address counter approaches its maximum threshold due to the unaccounted increments, the resolver begins dropping new client connections for duplicate queries without proper notification or graceful handling. This creates a cascading effect where legitimate client requests fail to resolve properly, leading to increased latency and potentially complete service unavailability for affected domains. The vulnerability's exploitable nature allows malicious actors to specifically target this weakness by crafting queries against slow-on-demand authoritative zones that force the counter to exceed its threshold, effectively creating a denial of service condition.
The root cause of this issue aligns with CWE-129 Input Validation and CWE-691 Insufficient Control Flow Management, as the system fails to properly validate configuration parameters and manage control flow within the expired query handling logic. From an ATT&CK framework perspective, this vulnerability maps to TA0005 Defense Evasion through the silent dropping of client requests and T1499 Endpoint Deviation for service degradation effects. The vulnerability's exploitation requires specific misconfiguration of the resolver parameters, making it a configuration-dependent attack vector that can be mitigated through proper parameter management.
Mitigation strategies must focus on both immediate configuration correction and long-term monitoring approaches. Administrators should immediately verify their Unbound configurations to ensure 'serve-expired-client-timeout' values are properly set above 'discard-timeout', with recommended defaults of 1800 for client timeout and 1900 for discard timeout. The system should also implement monitoring for reply address counter behavior and alert on unusual patterns that might indicate counter exhaustion. Additionally, regular security audits of DNS resolver configurations should be conducted to prevent similar misconfigurations that could lead to other control flow management vulnerabilities. Organizations should consider implementing rate limiting and query monitoring mechanisms to detect anomalous client behavior that might exploit this vulnerability, while also maintaining up-to-date installations of Unbound with the latest security patches to prevent exploitation of known vulnerabilities.