CVE-2026-50251 in Unbound
Summary
by MITRE • 07/22/2026
In NLnet Labs Unbound up to and including version 1.25.1, when 'unwanted-reply-threshold' is enabled (set to any value greater than zero), glue records of 0.0.0.0/::0 can short-circuit Unbound, on systems that can direct such traffic, by issuing DNS queries and receiving seemingly unwanted replies since the remote IP does not match the original source IP of 0.0.0.0/::0. This behavior keeps on looping for the glue records and pushing the counter to the configured 'unwanted-reply-threshold' that triggers a defensive cache clear. A malicious actor who controls a delegation that returns in-bailiwick glue of 0.0.0.0/::0 can drive the counter to the limit of 'unwanted-reply-threshold' to the threshold and trigger a cache clean of the message and rrset caches; at will, indefinitely, without sending a single spoofed packet. The iterator uses the 0.0.0.0/::0 glue, and a system that can route this (e.g., Linux kernel routes the datagram over loopback), Unbound's own listener answers from 127.0.0.1. Because of the mismatch of 0.0.0.0 and 127.0.0.1, in this example, Unbound accounts the reply as an unwanted (probably spoofed) answer. The counter resets to zero on every cache flush, so the attack loops forever.
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 in NLnet Labs Unbound DNS resolver versions 1.25.1 and earlier, specifically when the unwanted-reply-threshold configuration parameter is enabled. The flaw stems from how Unbound handles glue record validation when processing DNS delegation responses that contain 0.0.0.0/::0 addresses. When a malicious actor controls a delegation that returns in-bailiwick glue records with these null IP addresses, they can exploit a logical inconsistency in the resolver's defensive mechanism. The system uses the 0.0.0.0/::0 glue records and when the operating system routes this traffic through loopback interfaces such as Linux kernel routing, Unbound's listener responds from 127.0.0.1 address. This creates a mismatch between the expected source IP (0.0.0.0) and actual response IP (127.0.0.1), which Unbound interprets as potentially spoofed traffic. This misclassification triggers the unwanted reply counter mechanism that is designed to detect and mitigate DNS cache poisoning attacks, but in this case it becomes a vector for denial of service.
The technical exploitation occurs through a carefully crafted delegation that returns glue records with 0.0.0.0/::0 addresses, which are then processed by Unbound's iterative resolver. When the system routes these packets to loopback interfaces, the response comes from 127.0.0.1 instead of the expected 0.0.0.0 source, causing Unbound to increment its unwanted reply counter. Since no actual spoofed packets are transmitted during this process, the attack can be sustained indefinitely without generating network traffic that would typically trigger intrusion detection systems. The counter continues to increment until it reaches the configured unwanted-reply-threshold value, which triggers an automatic cache clearing operation that flushes both message and rrset caches. This cache clearing behavior creates a continuous loop where each cache flush resets the counter back to zero, allowing the attacker to maintain persistent disruption of the DNS service.
From a cybersecurity perspective, this vulnerability represents a classic case of resource exhaustion through logical flaw exploitation rather than traditional packet flooding attacks. The weakness aligns with CWE-362: Concurrent Execution using Shared Resource with Unprotected Race Condition and CWE-400: Uncontrolled Resource Consumption. The attack pattern follows ATT&CK technique T1496: Resource Hijacking, where an adversary consumes system resources to deny service to legitimate users. The vulnerability exploits the fundamental assumption that DNS responses should match expected source addresses in a predictable manner, but the routing behavior of modern operating systems creates an unexpected condition. The impact is particularly severe because it allows indefinite disruption without requiring spoofed packet generation, making it difficult to detect through conventional network monitoring approaches and essentially impossible to defend against using traditional rate limiting measures. Organizations using Unbound with unwanted-reply-threshold enabled should immediately upgrade to version 1.25.2 or later where this vulnerability has been patched.
The attack demonstrates how seemingly benign routing behaviors in operating systems can create unexpected security implications when combined with specific application logic. The flaw highlights the importance of considering all possible network path combinations when designing defensive mechanisms and underscores that cache validation systems must account for legitimate routing scenarios, not just potential attack vectors. This vulnerability serves as a reminder that DNS security mechanisms, while necessary, must be carefully designed to avoid creating new attack surfaces through logical inconsistencies in their implementation. The continuous loop created by the reset behavior after each cache flush makes this attack particularly insidious and difficult to distinguish from legitimate system behavior, potentially leading to extended service disruption without clear detection indicators.