---
id: "CVE-2026-35501"
kind: "vulnerability"
aliases: ["CVE-2026-35501"]
title: "Unbound: forged NSEC reply can mark a trust island as insecure"
severity: "low"
cvss: 3.7
epss: 0.0011
exploited: false
status: "open"
category: "package"
products: []
ecosystems: []
tags: ["dns", "dnssec", "package", "self-hosted", "unbound"]
not_affected_if: ["default-config", "no-extra-trust-anchor"]
published_at: "2026-10-21T09:17:07+00:00"
first_seen_at: "2026-10-23T21:57:28+00:00"
updated_at: "2026-10-25T04:43:35+00:00"
sources: [{"source": "nvd", "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-35501", "first_seen_at": "2026-10-23T21:57:28+00:00"}, {"source": "epss", "url": "https://api.first.org/data/v1/epss?cve=CVE-2026-35501", "first_seen_at": "2026-10-24T13:15:54+00:00"}]
---

# Unbound: forged NSEC reply can mark a trust island as insecure

Unbound 1.0.1 through 1.26.1 accepts and caches a forged NSEC reply without validating its signature when a root trust anchor and an extra trust-anchor for an island-of-security zone are both configured. An attacker can use this to make Unbound treat that configured trust island as insecure, bypassing DNSSEC validation for it.

_Summary, check and fix written by a model from the sources; labelled as such._

## How to check

- Run `unbound -V` to read the installed version and compare it to `1.26.1`.
- Check the configuration for `trust-anchor:` entries alongside a root trust anchor, for example with `grep -rn trust-anchor /etc/unbound/`.

## Fix

- Upgrade Unbound to a release newer than `1.26.1`; the sources do not name the exact fixed version, so check the NLnet Labs release notes.
- If upgrading is not possible, remove the extra island-of-security `trust-anchor:` entry only if your design allows it (unknown whether this fully mitigates).

## Timeline

- 2026-10-23T21:57:28+00:00 nvd https://nvd.nist.gov/vuln/detail/CVE-2026-35501
- 2026-10-24T13:15:54+00:00 epss https://api.first.org/data/v1/epss?cve=CVE-2026-35501

## From the sources

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.

---

_Free to read at a human pace. An API with keys and an MCP server are in preparation; early access: hello@infrastack.ai_