CVE-2026-77955 in Unbound
Summary
by MITRE • 09/16/2026
In NLnet Labs Unbound 1.13.2 up to and including 1.26.1, a vulnerability in ZONEMD configured zones (zonemd-check: yes) which are located below (but not at) a trust anchor allow for an attack window where (tampered with) zone contents are served (or stored to disk) prior to the ZONEMD integrity check. This is caused by the needed DS/DNSKEY asynchronous resolution that needs to happen before the ZONEMD check completes. If a zonefile is written to disk (zonefile: option) while the ZONEMD check failed, the tampered data are reloaded on startup and available until ZONEMD verification concludes again. If verification fails, the data is not served any more but still persists on disk for future reloads.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 09/21/2026
The vulnerability in NLnet Labs Unbound versions 1.13.2 through 1.26.1 represents a critical integrity bypass within the DNSSEC ZONEMD implementation, specifically affecting zones that reside below a trust anchor but are not themselves anchored by one. This flaw exploits the asynchronous nature of Domain System (DS) and DNSKEY record resolution, which is required to establish chain-of-trust validation before the Zone Message Digest (ZONEMD) integrity check can be fully completed. During this window where cryptographic verification is pending or in progress, an attacker with network interception capabilities or who has compromised a upstream resolver may serve tampered zone data that appears valid until the final ZONEMD signature verification occurs. This creates a transient but exploitable attack vector where maliciously altered DNS records can be processed and potentially cached by downstream resolvers before the integrity failure is detected.
The operational impact of this vulnerability is significantly amplified when the Unbound configuration includes the zonefile option, which instructs the server to persist loaded zones to disk for faster startup times or administrative management. If a tampered zone file is written to disk while the ZONEMD check has not yet completed successfully, that compromised data becomes part of the persistent storage layer. Upon subsequent restarts or reloads of the Unbound service, this corrupted zonefile is reloaded and served to clients before the asynchronous verification process can run again. This means that even if the live resolution eventually detects the integrity failure and stops serving the bad data for active queries during that specific session, the malicious records remain on disk. Consequently, every time the server restarts or reloads its configuration, it immediately begins serving tampered DNS responses until the background verification process catches up, effectively creating a persistent state of compromise that survives service interruptions.
From a technical perspective, this issue highlights a race condition between asynchronous cryptographic validation and synchronous data persistence mechanisms. The ZONEMD record is designed to provide integrity for zone contents at rest or in transit, but its effectiveness relies on the assumption that verification completes before any side effects like disk writes occur. In Unbound versions affected by this flaw, the architecture allows the write operation to proceed based on initial resolution success rather than final cryptographic validation. This decoupling of data persistence from complete integrity assurance violates the principle of least privilege and secure-by-default design, as it assumes that transient network conditions or slow upstream responses will not result in the acceptance of unverified data for storage. The vulnerability is particularly dangerous because it affects zones below a trust anchor, meaning they rely on parent zone delegation proofs which may also be subject to timing attacks or manipulation during the resolution process.
Mitigation strategies must address both the immediate configuration risks and the underlying architectural limitations. Administrators should immediately upgrade Unbound to version 1.26.2 or later, where this race condition has been resolved by ensuring that ZONEMD verification completes prior to any disk persistence operations for zones requiring integrity checks. For environments unable to update immediately, disabling the zonefile option is a critical temporary countermeasure; without persistent storage of loaded zones, the risk of reloading tampered data on startup is eliminated, although active queries may still be vulnerable during the resolution window. Additionally, enabling strict DNSSEC validation and ensuring that upstream resolvers are also patched helps reduce the attack surface for initial compromise. Monitoring logs for ZONEMD verification failures can provide early detection indicators, allowing administrators to identify when tampered data was served before being discarded.
This vulnerability aligns with CWE-362, Concurrent Execution using Shared Resource with Improper Synchronization of Resources, as it involves a race condition between asynchronous validation and synchronous file I/O operations. It also relates to CWE-157, Preference for Untrusted Data over Trusted Data, because the system prioritizes potentially unverified zone data for persistence based on initial resolution success rather than final cryptographic proof. In terms of MITRE ATT&CK framework tactics, this flaw facilitates Defense Evasion by allowing an attacker to maintain persistent access through compromised configuration files and impacts Availability via potential cache poisoning or misdirection if not detected. The asynchronous nature of the fix requirement underscores the complexity of securing DNS infrastructure where performance optimizations like caching and disk persistence must be carefully balanced against rigorous cryptographic verification timelines.