CVE-2026-35501: 
Unbound vulnerability analysis and mitigation

CVE-2026-35501 is a DNSSEC validation bypass vulnerability in NLnet Labs Unbound, a validating DNS resolver. When Unbound is configured with both a root trust anchor and an additional trust-anchor: for an island-of-security zone whose parent is provably insecure under the root chain, a network attacker can send a forged NSEC reply with the SOA bit cleared to trick Unbound into treating the configured trust island as insecure, effectively bypassing DNSSEC validation for that zone. The vulnerability affects Unbound versions 1.0.1 through 1.26.1 (inclusive), and is fixed in version 1.26.2. It carries a CVSS v3.1 base score of 3.7 (Low) (GitHub Advisory, NLnet Labs Advisory).

The root cause is classified as CWE-354 (Improper Validation of Integrity Check Value). Unbound's DNSSEC validator incorrectly accepts and caches an NSEC insecure response without performing the required RRSIG validation. This flaw originates from a legacy code fix intended to handle DS and NSEC queries from clients when a trust anchor for that name existed, which inadvertently allowed NSEC records to be accepted at the trust anchor apex without signature verification. An unauthenticated network attacker exploits this by injecting a forged NSEC reply with the SOA bit cleared, causing Unbound to cache the zone as insecure and subsequently accept unsigned or spoofed DNS responses for that zone. Exploitation requires the specific configuration of both a root trust anchor and a secondary trust anchor for an island-of-security zone with a provably insecure parent — a relatively uncommon but valid deployment scenario (GitHub Advisory, NLnet Labs Advisory).

Successful exploitation allows an attacker to undermine DNSSEC integrity for a configured trust island zone, causing Unbound to accept DNS responses for that zone without proper cryptographic validation. This creates an integrity impact — DNS responses for the affected zone can be spoofed or manipulated without detection by the resolver — potentially enabling DNS cache poisoning, traffic redirection, or man-in-the-middle attacks against services relying on that zone. There is no confidentiality or availability impact, and the scope is limited to the specific zone(s) configured as trust islands with insecure parents (GitHub Advisory).

There is no public proof-of-concept exploit code and no evidence of in-the-wild exploitation as of the disclosure date (GitHub Advisory). The EPSS score is 0.0, reflecting a very low probability of near-term exploitation. The vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. Exploitation requires high attack complexity — specifically, the ability to inject forged DNS responses into the resolver's query path — and the target must be running a non-default configuration with a secondary trust anchor for an island-of-security zone.

1. Reconnaissance: Identify Unbound resolver instances configured with both a root trust anchor and a secondary trust-anchor: directive for an island-of-security zone whose parent is provably insecure under the root chain. This configuration is non-default and must be confirmed before proceeding.
2. Position for DNS injection: Achieve a network position capable of intercepting or racing DNS responses to the target Unbound resolver — for example, via an on-path network position, BGP hijack, or DNS amplification/spoofing technique.
3. Craft forged NSEC reply: Construct a malicious NSEC DNS response for the trust island zone's apex with the SOA bit cleared in the NSEC bitmap, omitting a valid RRSIG record. This forged reply is designed to indicate the zone is insecure.
4. Inject the forged response: Send the crafted NSEC reply to the Unbound resolver in response to a query for the trust island zone, racing or replacing the legitimate authoritative response.
5. Trigger cache poisoning: Unbound accepts and caches the forged NSEC insecure response without RRSIG validation, marking the trust island zone as insecure in its cache.
6. Exploit the insecure state: With DNSSEC validation disabled for the zone, subsequently inject spoofed DNS responses for records within the trust island zone, redirecting traffic or performing man-in-the-middle attacks against dependent services (GitHub Advisory, NLnet Labs Advisory).

• Logs: Unbound log entries showing unexpected insecure validation status for zones that are configured with explicit trust-anchor: directives; log messages indicating NSEC records accepted at trust anchor apex without corresponding RRSIG validation.
• Network: Anomalous NSEC DNS responses arriving for trust island zone apexes with the SOA bit absent from the NSEC bitmap and no accompanying RRSIG record; unexpected DNS responses from non-authoritative sources for configured trust anchor zones.
• Cache State: Unbound cache inspection (via unbound-control dump_cache) showing trust island zones marked as insecure when they should be secure based on local trust anchor configuration.

The primary remediation is to upgrade NLnet Labs Unbound to version 1.26.2 or later, which contains the fix for this vulnerability (NLnet Labs Advisory, GitHub Advisory). If immediate patching is not possible, organizations should review whether their Unbound deployments use the specific configuration of a root trust anchor combined with a secondary trust-anchor: for an island-of-security zone with a provably insecure parent — if not, the risk is negligible. As an interim measure, monitor Unbound logs and cache state for unexpected insecure classifications of zones with configured trust anchors, and consider restricting network access to the resolver to reduce the attack surface for DNS response injection.