CVE-2026-50046 in Unbound
Summary
by MITRE • 07/22/2026
In NLnet Labs Unbound 1.15.0 up to and including 1.25.1, the TLS server name used for DNS-over-TLS (DoT) forwarded queries is tied to a struct's ('serviced_query') lifetime but also referenced by another struct ('waiting_tcp'). When the owning struct is jostled out of the mesh while the DoT TCP stream is still handshaking it frees the storage behind the referenced string and if the TLS stream then errors out, it dereferences the freed pointer. The dereference is read-only and the practical impact is a daemon crash resulting in denial of service. A malicious actor that knows a DoT forwarding/stub Unbound's configuration could exploit the vulnerability by quering records in the appropriate zone while keeping Unbound uder pressure so that the jostle logic kicks in. If answers for the vulnerable zone are slow, the likelihood of jostling such queries is higher, although the timing of the jostle needs to be precise. Requirements for a vulnerable Unbound is the existence of a stub/forward zone configured for DoT together with a configured '#authname' suffix on the server identification. The connectivity to the server needs to exhibit a transient failure at the correct time in order to kick off the vulnerable error path.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 07/22/2026
This vulnerability exists in NLnet Labs Unbound DNS resolver versions 1.15.0 through 1.25.1 and represents a classic use-after-free condition that can lead to denial of service. The flaw occurs during DNS-over-TLS operations when forwarding queries through DoT connections, specifically involving the interaction between two internal data structures: 'serviced_query' and 'waiting_tcp'. The TLS server name string is allocated within the 'serviced_query' structure's memory space but simultaneously referenced by the 'waiting_tcp' structure. When the garbage collection or jostling logic removes the 'serviced_query' from the processing mesh while a TCP TLS handshake is still in progress, the memory containing the server name string gets freed. However, if the TLS connection subsequently fails and attempts to access this freed memory location, it results in a read-only dereference of the freed pointer, causing the daemon to crash.
The vulnerability operates through a specific sequence of events that requires precise timing and particular configuration conditions to manifest successfully. The target system must have a stub or forward zone configured for DoT with a '#authname' suffix specified in the server identification configuration. This creates the necessary conditions where the TLS server name string becomes subject to memory management conflicts. An attacker exploiting this vulnerability would need to craft DNS queries that match records within zones configured for DoT forwarding while simultaneously maintaining pressure on the Unbound daemon to trigger the jostling logic. The attack becomes more likely when responses for vulnerable zones are delayed, increasing the probability that queries will be jostled out of the processing mesh during the critical TLS handshake phase.
From a cybersecurity perspective, this vulnerability maps directly to CWE-416 Use After Free and CWE-125 Out-of-bounds Read, both of which are classified under the Common Weakness Enumeration framework. The attack pattern aligns with ATT&CK technique T1499.004 Network Denial of Service, specifically targeting service availability through daemon crash exploitation. The operational impact is significant as it allows remote attackers to cause complete denial of service for the DNS resolver functionality without requiring authentication or privileged access. The vulnerability demonstrates poor memory management practices in the DNS resolver's TLS handling code, where the lifetime management of string references does not properly account for asynchronous operations that may outlive their originating data structures.
The exploitation requirements highlight the complexity of this vulnerability, as it necessitates understanding of both the Unbound internal architecture and specific timing conditions. The attacker must have knowledge of the target configuration to identify appropriate zones for querying and must be able to maintain network pressure to trigger the jostling behavior. This makes the vulnerability more difficult to exploit in practice but not impossible, particularly against systems with predictable query patterns or those using DoT forwarding configurations that are publicly known. The precise timing requirements suggest that this vulnerability may be more prevalent in high-traffic environments where the jostling logic is frequently activated due to resource constraints.
Mitigation strategies should focus on immediate patching of affected versions to address the memory management flaw in the TLS handling code. Organizations should also consider implementing monitoring for unusual daemon crashes or restart patterns, particularly in systems that use DoT forwarding configurations. Network administrators can reduce the attack surface by limiting DoT configurations where possible and ensuring proper resource allocation to prevent excessive jostling behavior. Additionally, regular security assessments of DNS resolver configurations should be conducted to identify and remediate similar memory management issues that could lead to similar vulnerabilities. The vulnerability demonstrates the importance of careful memory management in asynchronous network operations and serves as a reminder of the potential for seemingly benign configuration options to create serious security implications when combined with specific operational conditions.