CVE-2026-50106: Possible insecure NXDOMAIN for non-existing records under a configured island trust anchor underneath an insecure parent.
When NLnet Labs Unbound 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 who can deliver one forged NXDOMAIN response for a name inside the island, with the NSEC/SOA RRSIG 'SignerName' set to the insecure parent, tricks Unbound's validator to use the root trust anchor instead, and consecutively the insecure parent, thus causing that record to be treated as insecure and denying existence for records in the trust island.
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 run Unbound 1.26.1 or earlier 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 must be able to deliver a forged NXDOMAIN response for a name within the trust island. The response must include NSEC/SOA RRSIG records whose SignerName is set to the insecure parent.
What is the impact of a successful attack?
Unbound can validate using the root trust anchor and then the insecure parent rather than the island trust anchor. It consequently treats the target record as insecure and accepts denial of existence for records inside the trust island.