CVE-2026-35501: Bypass of a configured island trust anchor underneath an insecure parent from an atacker-controlled NSEC record.
When NLnet Labs Unbound 1.0.1 up to and including version 1.26.1 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 malicious actor with a forged NSEC reply with the SOA bit cleared can trick Unbound to treat the configured trust island as insecure. This happens because the DNSSEC validator in Unbound accepts and caches the NSEC insecure response bypassing the RRSIG validation that the validator was supposed to do. The acceptance of the NSEC record at the trust anchor apex was allowed due to and old fix for type DS and NSEC queries from clients when trust anchor for that name existed.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
NLnet Labs Unboundto a version that resolves this vulnerability.Fixed in 1.26.2
Event History
Frequently Asked Questions
Which deployments are affected?
Affected deployments use Unbound versions 1.0.1 through 1.26.1 and are 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.
What does an attacker need to exploit this issue?
An attacker needs to provide a forged NSEC reply with the SOA bit cleared. The attack relies on Unbound accepting and caching that insecure NSEC response without the intended RRSIG validation.
What is the practical security impact?
The forged response can cause Unbound to treat the configured trust-island zone as insecure, bypassing the configured trust anchor for that zone. The supplied severity vector indicates integrity impact only, with no confidentiality or availability impact.