CVE-2026-50252 in Unbound
Summary
by MITRE • 07/22/2026
In NLnet Labs Unbound 1.4.22 up to and including 1.25.1, UDP source port is randomized and intended to serve as a secret value that increases the entropy of DNS transactions. When resolver load balancing policies depend on the source port while their outcome is revealed this secrecy is undermined. The vulnerability arises when the load balancing policy is consistent with respect to the incoming source UDP port and IP address while heavily depending on the incoming source UDP port as a randomization source. When the SO_REUSEPORT configuration option is enabled ('so-reuseport: yes') in Unbound (by default), it meets these conditions, making it vulnerable for DNS cache poisoning attacks. Upon startup, Unbound randomly partitions the available UDP source port space into disjoint subsets of (almost) equal size, assigning each subset to a specific worker thread. When an incoming DNS query is received, the kernel’s SO_REUSEPORT load balancing mechanism deterministically assigns the query to a socket associated with a particular thread. All outgoing DNS queries generated during the resolution of that request use source ports selected exclusively from the port subset assigned to the corresponding thread. Since these port subsets are disjoint across threads, the source port observed in a resolver’s outgoing query to an authoritative name server serves as a reliable indicator of the worker thread that processed the original client query. A malicious actor can acquire the mapping between incoming UDP source ports (for a given fixed source IP address) and Unbound worker threads and leverage it to conduct DNS cache poisoning attacks by effectively lowering the random port population per thread.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 07/23/2026
This vulnerability in NLnet Labs Unbound affects versions 1.4.22 through 1.25.1 and stems from a fundamental flaw in how source port randomization interacts with load balancing mechanisms. The core issue manifests when the resolver's load balancing policy relies heavily on the source UDP port while simultaneously revealing the outcome of that policy through network traffic analysis. This creates a situation where the intended security benefit of source port randomization becomes counterproductive rather than protective. When Unbound operates with the so-reuseport configuration enabled, which is the default setting, it creates predictable patterns that adversaries can exploit. The vulnerability specifically exploits the combination of SO_REUSEPORT functionality and thread-based port partitioning to undermine the security assumptions underlying DNS transaction randomization.
The technical mechanism behind this vulnerability involves the deterministic assignment of incoming queries to worker threads through the kernel's SO_REUSEPORT load balancing. During startup, Unbound partitions the available UDP port space into distinct subsets, with each subset exclusively assigned to a specific worker thread. When a client query arrives, the kernel's load balancing algorithm deterministically routes it to a socket associated with a particular thread, meaning all subsequent outgoing queries from that resolution process use source ports exclusively from that thread's designated subset. This creates a direct correlation between the source port observed in outbound queries and the worker thread that originally processed the client request, effectively compromising the randomness that should make DNS cache poisoning attacks more difficult.
The operational impact of this vulnerability is significant for DNS resolver security, particularly in environments where Unbound serves as a recursive resolver with SO_REUSEPORT enabled. An attacker who can monitor incoming DNS queries from a specific source IP address can map the relationship between incoming source ports and worker threads by observing the outbound queries that result from those connections. This mapping allows the adversary to predict which thread will handle future queries from that same source, fundamentally reducing the entropy of the source port space per thread. The vulnerability creates a pathway for DNS cache poisoning attacks where an attacker can effectively lower the randomization population by focusing their efforts on specific thread assignments rather than having to brute force across the entire port space.
This vulnerability directly relates to CWE-310 and CWE-327, which address cryptographic weaknesses and improper randomness in security-critical applications. The flaw demonstrates how seemingly benign configuration options can create serious security implications when combined with other system behaviors. From an ATT&CK perspective, this represents a technique for privilege escalation and information gathering through network traffic analysis and cache poisoning attacks. The vulnerability also aligns with the broader category of side-channel attacks where implementation details leak information that undermines security controls. Organizations using Unbound in production environments should consider disabling so-reuseport if they cannot ensure proper network segmentation or if their threat model includes sophisticated adversaries capable of performing this type of traffic analysis and mapping.
Mitigation strategies include disabling the so-reuseport configuration option when DNS cache poisoning resistance is a primary concern, though this may impact performance. Administrators should also implement network segmentation to limit the ability of attackers to perform the necessary traffic monitoring required for exploitation. Regular updates to Unbound versions that address this specific vulnerability are essential, as newer releases may include fixes that either eliminate the problematic behavior or provide better controls over load balancing mechanisms. Additionally, organizations should monitor DNS query patterns and implement anomaly detection systems that can identify unusual source port distributions that might indicate exploitation attempts. The most effective long-term solution involves ensuring that all components of the DNS resolution process maintain proper entropy in their randomization mechanisms while avoiding combinations that create predictable patterns for attackers to exploit.