CVE-2026-56416 in Unbound
Summary
by MITRE • 07/22/2026
In NLnet Labs Unbound up to and including version 1.25.1, when the validator builds the canonical RDATA form for an RRSIG-covered PX/RP/MINFO/SOA RRset, it computes the address of the second embedded domain name as 'datstart + dname_valid(datstart, ...)' and passes it straight to 'query_dname_tolower()' without checking that a second name is actually present in the RDATA. The wire-format parser accepts multi-dname RRs whose RDATA ends after the first name, so an attacker who runs a DNSSEC-signed authoritative server can deliver a record with an absent second domain name (e.g. SOA record) and cause 'query_dname_tolower()' to walk label-by-label through stale bytes in the per-worker 'env->scratch_buffer', past the end of that heap allocation if 'msg-buffer-size' has been lowered from the default. This leads to heap buffer overflow and on a release build the outcome relies heavily on the contents of the buffer tail and the adjacent heap chunk.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 07/22/2026
This vulnerability exists in NLnet Labs Unbound DNS resolver versions 1.25.1 and earlier, where the validator component fails to properly validate the presence of multiple domain names within RRSIG-signed resource record sets. The flaw manifests specifically when processing PX/RP/MINFO/SOA RRsets, which can contain two domain names in their RDATA format. The canonical RDATA computation routine incorrectly assumes that a second domain name is always present and directly passes the calculated address to query_dname_tolower() function without prior validation.
The technical implementation error stems from the validator's wire-format parsing logic that accepts records where the RDATA terminates after the first domain name, leaving the second name field absent or undefined. When the canonical form construction proceeds, it calculates the address of what should be the second domain name using datstart + dname_valid(datstart, ...) without verifying that a second name actually exists within the RDATA structure. This oversight creates a path where the query_dname_tolower() function receives an invalid memory pointer pointing into uninitialized heap memory within the worker thread's scratch_buffer allocation.
The operational impact of this vulnerability represents a critical heap buffer overflow condition that can be exploited by malicious DNSSEC-signed authoritative servers. Attackers can craft specially formatted records with missing second domain names, causing the resolver to traverse beyond the bounds of the allocated scratch_buffer memory. When the 'msg-buffer-size' parameter has been reduced from its default settings, this traversal can extend past the heap allocation boundaries into adjacent memory chunks, potentially leading to memory corruption that may be exploited for arbitrary code execution.
This vulnerability aligns with CWE-121 Heap-based Buffer Overflow and represents a classic case of inadequate bounds checking in memory management operations. The flaw demonstrates poor input validation practices where the software assumes the presence of expected data structures without proper verification. From an ATT&CK perspective, this represents a privilege escalation vector through DNS cache poisoning and memory corruption techniques that could potentially allow attackers to execute arbitrary code on vulnerable systems.
The recommended mitigations include immediate patching to versions beyond 1.25.1 where this validation has been implemented, implementing stricter input validation for multi-domain name RRs in the wire-format parser, and ensuring proper bounds checking before any memory traversal operations. Additionally, system administrators should monitor for suspicious DNSSEC-signed records and consider implementing defensive measures such as limiting the msg-buffer-size parameter to prevent excessive heap allocation that could amplify the impact of such buffer overflows.