CVE-2026-55708 in Unbound
Summary
by MITRE • 07/22/2026
In NLnet Labs Unbound 1.6.0 up to and including 1.25.1, the 'view_local_data' and 'view_local_datas' commands of 'unbound-control' create a bare local zones tree for an already configured named view when the view is configured with no local data to begin with. However, the creation through the control interface omits adding the default-protected zones (e.g., RFC 1918 reverse, AS112 zones, .onion, .localhost). Once the local zone tree exists without the defaults, every query for a default-protected name from a client mapped to that view escapes to the public DNS via the iterator instead of being answered locally, bypassing local policy expectations.
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 versions 1.6.0 through 1.25.1 where the unbound-control utility's view_local_data and view_local_datas commands fail to properly initialize local zone trees when invoked on views configured without initial local data. The flaw stems from an incomplete implementation that creates bare local zones without incorporating the standard default-protected zones that are typically included in DNS resolver configurations. These missing zones include critical RFC 1918 reverse zones, AS112 service zones, .onion domain resolution zones, and .localhost entries that form the foundation of proper DNS resolution policies.
The technical implementation issue manifests when administrators use the unbound-control interface to dynamically add local data to views that were initially configured without any local zone information. The system creates a local zones tree structure but omits the essential default-protected zones that should be present in every properly configured DNS resolver environment. This omission occurs specifically during the dynamic creation phase of the view's local zone configuration, bypassing the normal initialization process that would include these critical zones by default.
The operational impact of this vulnerability is significant as it fundamentally undermines local DNS policy enforcement and security expectations within the resolver environment. When queries for default-protected names are made through clients mapped to affected views, the resolver fails to provide local responses and instead forwards these queries to the public DNS infrastructure via the iterative resolution process. This behavior bypasses any local access controls, caching policies, or internal DNS resolution rules that administrators expect to govern these specific name spaces, effectively exposing internal network resources to external DNS resolution.
This vulnerability aligns with CWE-1198 which addresses improper handling of protected zones in DNS implementations and represents a critical configuration management flaw that violates fundamental DNS security principles. The issue creates an attack surface where malicious actors could potentially exploit the missing default protections to perform DNS tunneling, bypass access controls, or gain information about internal network structures through public DNS queries. From an ATT&CK perspective, this vulnerability maps to TA0011 (Command and Control) and TA0001 (Initial Access) as it enables unauthorized external resolution of internal domain names that should remain protected within the local DNS environment.
The recommended mitigation involves upgrading to NLnet Labs Unbound versions beyond 1.25.1 where this issue has been addressed in the codebase. Administrators should also implement strict monitoring of unbound-control usage and verify that all views contain complete local zone configurations including default-protected zones. Additionally, organizations should consider implementing network-level controls that prevent unauthorized access to the unbound-control interface and establish automated verification processes to ensure that all configured views maintain proper default-protected zone inclusion. The fix in newer versions ensures that when local data is dynamically added through the control interface, the complete set of default-protected zones is properly initialized alongside the user-defined local data, maintaining consistency with standard DNS resolver security practices and policy enforcement requirements.