NLnet Labs has released Unbound version 1.25.1 to address CVE-2026-42944, a high-severity heap-based buffer overflow vulnerability in its popular DNS resolver software. The flaw, disclosed on May 20, 2026, affects Unbound versions 1.14.0 through 1.25.0 on all platforms, including Windows, and could allow remote code execution or denial of service when the resolver processes maliciously crafted DNS queries.

The vulnerability is not in the Windows DNS Server role or any built-in Windows component. It exists solely in Unbound, an open-source recursive DNS resolver often used by privacy-focused individuals, network appliances, and enterprise environments seeking full control over DNS resolution. For Windows enthusiasts who run Unbound locally—perhaps inside WSL, Docker containers, or as a standalone service—this vulnerability demands immediate attention.

Technical details: how a crafted NSID option triggers a heap overflow

CVE-2026-42944 resides in Unbound’s handling of the EDNS0 NSID (Name Server Identifier) option, defined in RFC 5001. The NSID option allows a DNS client to request identity information from authoritative servers. While legitimate queries typically include at most one NSID option, an attacker can craft a packet containing multiple NSID options to trip Unbound’s processing logic.

The root cause is a missing bounds check when unpacking and storing NSID option data. Unbound’s parser allocates a fixed-size heap buffer for the option content but does not verify that the total length of concatenated NSID options fits within that buffer. When multiple NSID payloads are presented, an overflow occurs, corrupting adjacent heap memory. Such corruption can be leveraged to overwrite function pointers, heap metadata, or other critical structures, potentially leading to arbitrary code execution with the privileges of the Unbound process.

Exploitation typically requires the attacker to be able to send queries directly to the resolver. If Unbound is configured to accept queries from the public internet (e.g., an open resolver), remote exploitation becomes trivial. In more common deployments where Unbound listens only on localhost, an attacker would need a foothold on the local machine or the ability to trick a local application into sending specially crafted DNS requests. Even in the absence of code execution, heap corruption can reliably crash the Unbound service, causing a denial of service for dependent applications and users.

Affected versions and severity

The issue was introduced in Unbound 1.14.0 and is present in all versions up to and including 1.25.0. The NLnet Labs security advisory classifies the vulnerability as “high” severity. While an official CVSS score was not immediately published, similar heap overflows in DNS resolvers often score in the 7.0–8.9 range due to the potential for remote code execution without authentication.

Systems running older versions of Unbound (prior to 1.14.0) are not affected. The flaw is platform-independent, meaning Windows, Linux, macOS, and BSD systems are equally vulnerable when using an affected build.

Resolution: upgrade to Unbound 1.25.1

The sole and preferred mitigation is to upgrade to Unbound 1.25.1, which NLnet Labs released simultaneously with the advisory. The fix implements proper validation of the number of NSID options and ensures that the allocated buffer cannot be exceeded. Administrators should prioritize this update, particularly on any system where Unbound is internet-facing or serves as the primary DNS resolver for critical workloads.

For those who compile Unbound from source, the patch is available in the project’s GitHub repository and tarball downloads. Binary packages for various Linux distributions, FreeBSD, and Windows will be updated by maintainers over the following days. On Windows, users who installed Unbound via the official NSIS installer or through a package manager like Chocolatey can check for version 1.25.1 and re-install manually if the package repositories are not yet up to date.

Workarounds and mitigating factors

While no practical workaround exists within Unbound’s configuration to reject NSID-based attacks without disabling the functionality entirely (which would require a custom build), the following factors can reduce immediate risk:

  • Listen on localhost only: If your Unbound instance is bound to 127.0.0.1 or ::1 and not accessible from the network, remote exploitation is impossible. This is the default configuration in many packages.
  • Network segmentation: For Unbound deployments serving a private network, ensure that access to the resolver (port 53) is restricted via firewall rules to trusted subnets only.
  • EDNS0 filtering: A stateful firewall or Intrusion Prevention System could be configured to drop DNS queries containing multiple NSID options. However, this requires deep packet inspection and is not universally feasible.
  • Monitoring: Audit logs for unusual DNS queries or repeated crashes of the Unbound service. Sudden segmentation faults or heap corruption errors in logs may indicate exploitation attempts.

Nevertheless, these measures are only temporary. Applying the upgrade remains the definitive solution.

How to verify your version and detect exploitation

Administrators can check the currently running Unbound version with:

unbound -V

or by querying the running daemon if remote control is enabled:

unbound-control status

The output will show the version string. Any version between 1.14.0 and 1.25.0 inclusive requires an immediate update.

To detect potential exploitation attempts, examine Unbound’s query logs for anomalous NSID activity. While Unbound does not log EDNS0 option content by default, enabling val-log-level: 2 or higher in unbound.conf may reveal malformed queries. System logs may also contain entries about crashes or memory corruption if repeated attempts have occurred. Given the relative rarity of NSID queries in normal operation, a sudden spike in NSID-related traffic could be a strong indicator.

Broader implications: not just a Windows concern—but Windows users should care

The vulnerability has been incorrectly associated with Windows DNS Server in some early discussions, likely because of the “higher-than-usual” profile of DNS security flaws in the Microsoft ecosystem. To be absolutely clear: CVE-2026-42944 is not a vulnerability in Microsoft Windows DNS Server, the DNS Client service, or any native Windows component. It is a bug in a third-party recursive resolver that many tech-savvy Windows users choose to run alongside or instead of the operating system’s default stub resolver.

Windows users who have installed Unbound to gain full recursive resolution, for DNS over TLS (DoT), or for advanced caching—often motivated by privacy or performance—must update manually. Unbound does not auto-update, so merely relying on Windows Update will not address this flaw. Moreover, Unbound is frequently embedded in network appliances, routers, and security products that run on Windows or Linux substrates. Enterprises should contact their appliance vendors to confirm whether they bundle an affected Unbound version and to obtain patched firmware.

The vulnerability also highlights a recurring challenge in the open-source DNS ecosystem: the adoption of modern protocol extensions without thorough fuzzing. The EDNS0 framework, while essential for DNS evolution, introduces a broad attack surface. NLnet Labs has historically maintained a strong security posture, but this incident reinforces the need for continuous fuzzing and code audits, especially in code paths handling complex option parsing.

The path forward: patching and hardening

For the typical Windows news reader, the takeaway is straightforward:

  1. Identify if Unbound exists on your machine. Search for unbound.exe in program files, check your package manager, or look at the output of netstat -ano for a service listening on port 53.
  2. Check the version using the commands above.
  3. Update to Unbound 1.25.1 immediately from the official NLnet Labs website.
  4. Re-evaluate whether Unbound needs to be internet-facing. If you use it only for local resolution, ensure it binds to localhost interfaces.

Beyond this specific CVE, system administrators should treat DNS resolvers as critical infrastructure. Regular patching, configuration review, and network-level access controls are essential. The relative obscurity of Unbound on Windows does not diminish the risk; in fact, it may mean that many installations are less rigorously monitored and updated.

As always, coordinated disclosure by NLnet Labs has prevented a zero-day exploitation scenario. No active attacks targeting this specific flaw have been publicly reported at the time of disclosure. However, with the vulnerability details now available, it is only a matter of time before proof-of-concept code circulates. Prompt action by Unbound operators will keep the window of exposure to a minimum.

Conclusion

CVE-2026-42944 serves as an important reminder that even well-trusted open-source DNS tools are susceptible to dangerous coding mistakes. The fix is simple, but the onus is on administrators to recognize that this update is necessary. For Windows users, the episode also clarifies a point of confusion: this is not a Microsoft problem, but rather a third-party vulnerability that can exist on any platform. Check your systems, update to Unbound 1.25.1, and verify that your DNS resolution chain is as resilient as you assume it to be.