CVE-2026-42959

What it actually does

This vulnerability affects the DNSSEC validator in NLnet Labs Unbound versions up to and including 1.25.0. A malicious DNSSEC-signed domain can return specially crafted upstream DNS replies that cause Unbound to construct validation chase-reply data incorrectly. Specifically, incorrect counter use while calculating write offsets for ADDITIONAL section RRsets can leave an uninitialized array slot when DNAME duplication increases ANSWER records and AUTHORITY filtering decreases AUTHORITY records. The validator can later dereference that uninitialized pointer, causing the Unbound process to crash. The impact is unauthenticated, network-reachable denial of service against recursive resolvers that perform DNSSEC validation.

Why it matters to the business

Organizations using vulnerable Unbound resolvers may experience DNS resolution outages if an attacker can cause clients or systems to query an attacker-controlled domain. Because DNS is a dependency for web access, email delivery, identity services, software updates, monitoring, and many internal applications, a resolver crash can create broad operational disruption even though the flaw does not provide code execution or data theft. The CVSS availability impact is high, but EPSS is currently low and stable, it is not known to be in CISA KEV, and no public exploit maturity is reported; remediation should still be prioritized for internet-facing or business-critical resolvers.

How an attack unfolds

An attacker first controls or configures a DNSSEC-signed domain. They craft DNS responses involving a DNAME chain with unsigned CNAMEs, unsigned AUTHORITY records, and signed ADDITIONAL glue records in a combination that triggers the validator’s inconsistent section accounting. The attacker then causes a vulnerable Unbound resolver to query that domain, either directly if they can send recursive queries to the resolver or indirectly by inducing a user, service, crawler, email gateway, security scanner, or application to resolve attacker-controlled names. When the vulnerable resolver receives the malicious upstream reply and performs DNSSEC validation, it constructs chase-reply messages using incorrect offsets, dereferences an uninitialized pointer, and the Unbound daemon crashes. Repeated queries can be used to keep the resolver unstable until it is patched, mitigated, or protected by service supervision and filtering.

How to fix it

Upgrade NLnet Labs Unbound to version 1.25.1 or later, which fixes the counter and offset calculation error in chase-reply construction. Treat all Unbound versions up to and including 1.25.0 as affected. Where immediate upgrade is not possible, reduce exposure by restricting who can send recursive queries to the resolver, blocking open-recursive access from untrusted networks, using firewall or ACL controls around port 53 TCP/UDP, and ensuring service supervision restarts Unbound after crashes. Avoid disabling DNSSEC validation as a primary mitigation unless the operational risk is explicitly accepted, because that weakens DNS integrity protections. Deploy redundant resolvers so a single daemon crash does not cause organization-wide DNS outage.

How to confirm the fix worked

Confirm the installed Unbound version is 1.25.1 or later using package manager metadata or `unbound -V`. Verify that running resolver instances were restarted after upgrade and are using the patched binary, not only that packages were installed. Check configuration management, containers, appliances, and statically bundled deployments for embedded Unbound versions. Validate that recursive service is not exposed as an open resolver by testing from untrusted networks and confirming ACLs restrict recursion to intended clients. Review service health after patching for absence of repeated crashes, core dumps, or systemd restart loops related to the Unbound process.

Typical attack path

1. Identify or assume a target organization uses Unbound 1.25.0 or earlier as a recursive validating resolver.
2. Register or control a DNSSEC-signed domain and configure records that create the required DNAME/CNAME/AUTHORITY/ADDITIONAL response structure.
3. Trigger the target resolver to look up a name under the malicious domain, either by direct recursive query access or by inducing another system to perform DNS resolution.
4. The vulnerable Unbound instance receives the malicious upstream reply and enters DNSSEC validation logic.
5. Incorrect chase-reply offset calculation creates an uninitialized pointer condition.
6. The validator dereferences the uninitialized pointer and the Unbound process crashes.
7. If the service automatically restarts, repeat triggering queries can cause recurring DNS resolver outages.

How to detect it

To determine whether exploitation may have already occurred, correlate Unbound service crashes with DNS query and response activity immediately before the crash. Review syslog, journald, kernel logs, Unbound logs, service manager logs, package/container logs, and crash dump locations for segmentation faults, core dumps, abnormal exits, or restart loops involving the `unbound` process. If query logging or passive DNS telemetry is available, look for queries to unusual or newly seen DNSSEC-signed domains shortly before each crash, especially domains returning DNAME chains, CNAMEs, AUTHORITY records, and ADDITIONAL glue. Also inspect monitoring data for short DNS outage windows, spikes in resolver restart counts, sudden drops in successful responses, SERVFAIL increases, or resolver availability alerts. Because the malicious domain and record contents are attacker-controlled and no universal exploit domain is known, detection should focus on crash artifacts and time-correlated DNS lookups rather than fixed network indicators.

• unbound
• unbound.service
• unbound.*segfault
• segfault.*unbound
• unbound.*core dumped
• Main process exited, code=dumped
• status=11/SEGV
• unbound.service: Failed with result 'core-dump'
• unbound.service: Scheduled restart job
• kernel: unbound[
• /var/lib/systemd/coredump/
• /var/crash/
• /var/log/unbound/
• /var/log/syslog
• /var/log/messages

What your security team should do

• Inventory all systems, containers, appliances, and DNS platforms running NLnet Labs Unbound and identify versions up to and including 1.25.0.
• Prioritize upgrade to Unbound 1.25.1 or later for internet-facing, shared, high-volume, and business-critical recursive resolvers.
• Restrict recursive DNS access to authorized clients only; ensure vulnerable or unpatched resolvers are not reachable as open resolvers from the internet.
• Enable or verify high-availability DNS resolver architecture so a single process crash does not disrupt enterprise name resolution.
• Monitor Unbound, systemd, syslog, kernel, and crash dump telemetry for segfaults, core dumps, or repeated restarts of the Unbound daemon.
• Review DNS query logs for unusual or repeated queries to newly observed DNSSEC-signed domains immediately preceding Unbound crashes.
• If repeated crashes are observed before patching, preserve logs and core files for forensic analysis and consider temporarily blocking suspicious triggering domains or upstream responses where feasible.