{"id":"CVE-2026-35501","aliases":["AZL-109821","CLSA-2026-1792810088","CLSA-2026-1792810562","DEBIAN-CVE-2026-35501","EUVD-2026-107151","GHSA-mh74-9w87-h7vx","MGASA-2026-0571","OESA-2026-4732","OESA-2026-4733","OESA-2026-4734","UBUNTU-CVE-2026-35501","openSUSE-SU-2026:12257-1"],"status":"published","title":"Bypass of a configured island trust anchor underneath an insecure parent from an atacker-controlled NSEC record.","description":"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.","severity":{"version":"3.1","score":3.7,"vector":"CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:L/A:N","level":"low","assessor":"cna","from":"cve"},"epss":{"day":"2026-11-09","score":0.00111,"percentile":0.01329,"model":"v2026.06.15"},"facts":{"in_kev":false,"known_exploited":false,"public_exploit":false,"fix_available":true},"cwes":["CWE-354"],"published":"2026-10-21T08:56:55Z","modified":"2026-11-06T14:16:53Z","fixes":[{"ecosystem":"Azure Linux:3","package":"unbound","fixed_in":["1.26.2-1"],"sources":["osv"]},{"ecosystem":"Debian:13","package":"unbound","fixed_in":["1.26.2-0+deb13u1"],"sources":["osv"]},{"ecosystem":"Debian:14","package":"unbound","fixed_in":["1.26.2-1"],"sources":["osv"]}],"affected":[{"source":"osv","ecosystem":"Azure Linux:3","package":"unbound","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"1.26.2-1"}]}]},{"source":"osv","ecosystem":"TuxCare:RHEL:7","package":"unbound","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"1.6.6-5.0.1.el7_8.tuxcare.els3"}]}],"bundled":6},{"source":"osv","ecosystem":"TuxCare:RHEL:7","package":"unbound-devel","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"1.6.6-5.0.1.el7_8.tuxcare.els3"}]}],"bundled":6},{"source":"osv","ecosystem":"TuxCare:RHEL:7","package":"unbound-libs","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"1.6.6-5.0.1.el7_8.tuxcare.els3"}]}],"bundled":6},{"source":"osv","ecosystem":"TuxCare:RHEL:7","package":"unbound-python","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"1.6.6-5.0.1.el7_8.tuxcare.els3"}]}],"bundled":6},{"source":"osv","ecosystem":"TuxCare:OracleLinux:7","package":"unbound","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"1.6.6-5.0.1.el7_8.tuxcare.els3"}]}],"bundled":6},{"source":"osv","ecosystem":"TuxCare:OracleLinux:7","package":"unbound-devel","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"1.6.6-5.0.1.el7_8.tuxcare.els3"}]}],"bundled":6},{"source":"osv","ecosystem":"TuxCare:OracleLinux:7","package":"unbound-libs","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"1.6.6-5.0.1.el7_8.tuxcare.els3"}]}],"bundled":6},{"source":"osv","ecosystem":"TuxCare:OracleLinux:7","package":"unbound-python","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"1.6.6-5.0.1.el7_8.tuxcare.els3"}]}],"bundled":6},{"source":"osv","ecosystem":"Debian:12","package":"unbound","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["1.17.1-2","1.17.1-2+deb12u1","1.17.1-2+deb12u2","1.17.1-2+deb12u3","1.17.1-2+deb12u4","1.17.1-2+loong64","1.18.0-1","1.18.0-2","1.19.1-1","1.19.2-1","1.20.0-1","1.21.1-1","1.22.0-1","1.22.0-2","1.23.1-1","1.24.0-1","1.24.0-2","1.24.1-1","1.24.1-2","1.24.2-1","1.25.0-1","1.25.1-1","1.25.2-1","1.26.0-1","1.26.0-2","1.26.1-1","1.26.2-1"]},{"source":"osv","ecosystem":"Debian:13","package":"unbound","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"1.26.2-0+deb13u1"}]}],"versions":["1.22.0-2","1.22.0-2+deb13u1","1.22.0-2+deb13u2","1.22.0-2+deb13u3","1.23.1-1","1.24.0-1","1.24.0-2","1.24.1-1","1.24.1-2","1.24.2-1","1.25.0-1","1.25.1-1","1.25.2-1","1.26.0-1","1.26.0-2","1.26.1-0+deb13u1","1.26.1-1"]},{"source":"osv","ecosystem":"Debian:14","package":"unbound","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"1.26.2-1"}]}],"versions":["1.22.0-2","1.23.1-1","1.24.0-1","1.24.0-2","1.24.1-1","1.24.1-2","1.24.2-1","1.25.0-1","1.25.1-1","1.25.2-1","1.26.0-1","1.26.0-2","1.26.1-1"]},{"source":"osv","ecosystem":"Mageia:10","package":"unbound","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"1.26.2-1.mga10"}]}],"bundled":5},{"source":"osv","ecosystem":"openEuler:22.03-LTS-SP4","package":"unbound","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"1.13.2-31.oe2203sp4"}]}],"bundled":4},{"source":"osv","ecosystem":"openEuler:24.03-LTS-SP1","package":"unbound","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"1.17.1-25.oe2403sp1"}]}],"bundled":4},{"source":"osv","ecosystem":"openEuler:24.03-LTS-SP3","package":"unbound","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"1.17.1-25.oe2403sp3"}]}],"bundled":4},{"source":"osv","ecosystem":"Ubuntu:Pro:14.04:LTS","package":"unbound","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["1.4.20-1","1.4.21-1","1.4.21-1ubuntu1","1.4.21-1ubuntu2","1.4.22-1ubuntu1","1.4.22-1ubuntu2","1.4.22-1ubuntu3","1.4.22-1ubuntu4","1.4.22-1ubuntu4.14.04.1","1.4.22-1ubuntu4.14.04.2","1.4.22-1ubuntu4.14.04.3","1.4.22-1ubuntu4.14.04.3+esm1","1.4.22-1ubuntu4.14.04.3+esm2","1.4.22-1ubuntu4.14.04.3+esm3","1.4.22-1ubuntu4.14.04.3+esm4","1.4.22-1ubuntu4.14.04.3+esm5"]},{"source":"osv","ecosystem":"Ubuntu:Pro:16.04:LTS","package":"unbound","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["1.4.22-1ubuntu6","1.5.7-1ubuntu1","1.5.7-1ubuntu2","1.5.8-1ubuntu1","1.5.8-1ubuntu1.1","1.5.8-1ubuntu1.1+esm1","1.5.8-1ubuntu1.1+esm2","1.5.8-1ubuntu1.1+esm3","1.5.8-1ubuntu1.1+esm4","1.5.8-1ubuntu1.1+esm5"]},{"source":"osv","ecosystem":"Ubuntu:Pro:18.04:LTS","package":"unbound","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["1.6.5-1","1.6.7-1","1.6.7-1build1","1.6.7-1ubuntu1","1.6.7-1ubuntu2","1.6.7-1ubuntu2.1","1.6.7-1ubuntu2.2","1.6.7-1ubuntu2.3","1.6.7-1ubuntu2.4","1.6.7-1ubuntu2.5","1.6.7-1ubuntu2.6","1.6.7-1ubuntu2.6+esm2","1.6.7-1ubuntu2.6+esm3","1.6.7-1ubuntu2.6+esm4","1.6.7-1ubuntu2.6+esm5","1.6.7-1ubuntu2.6+esm6"]},{"source":"osv","ecosystem":"Ubuntu:Pro:20.04:LTS","package":"unbound","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["1.9.0-2ubuntu1","1.9.0-2ubuntu2","1.9.4-2","1.9.4-2ubuntu1","1.9.4-2ubuntu1.1","1.9.4-2ubuntu1.2","1.9.4-2ubuntu1.3","1.9.4-2ubuntu1.4","1.9.4-2ubuntu1.5","1.9.4-2ubuntu1.6","1.9.4-2ubuntu1.8","1.9.4-2ubuntu1.9","1.9.4-2ubuntu1.11","1.9.4-2ubuntu1.11+esm1","1.9.4-2ubuntu1.11+esm2","1.9.4-2ubuntu1.11+esm3"]},{"source":"osv","ecosystem":"Ubuntu:22.04:LTS","package":"unbound","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["1.13.1-1ubuntu1","1.13.1-1ubuntu3","1.13.1-1ubuntu5","1.13.1-1ubuntu5.1","1.13.1-1ubuntu5.2","1.13.1-1ubuntu5.3","1.13.1-1ubuntu5.4","1.13.1-1ubuntu5.5","1.13.1-1ubuntu5.7","1.13.1-1ubuntu5.8","1.13.1-1ubuntu5.10","1.13.1-1ubuntu5.11","1.13.1-1ubuntu5.12","1.13.1-1ubuntu5.13","1.13.1-1ubuntu5.14","1.13.1-1ubuntu5.15","1.13.1-1ubuntu5.16","1.13.1-1ubuntu5.17"]},{"source":"osv","ecosystem":"Ubuntu:24.04:LTS","package":"unbound","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["1.17.1-2","1.18.0-2ubuntu1","1.18.0-2ubuntu2","1.19.1-1ubuntu1","1.19.2-1ubuntu1","1.19.2-1ubuntu3","1.19.2-1ubuntu3.1","1.19.2-1ubuntu3.2","1.19.2-1ubuntu3.3","1.19.2-1ubuntu3.4","1.19.2-1ubuntu3.5","1.19.2-1ubuntu3.6","1.19.2-1ubuntu3.7","1.19.2-1ubuntu3.8","1.19.2-1ubuntu3.9","1.19.2-1ubuntu3.10","1.19.2-1ubuntu3.12"]},{"source":"osv","ecosystem":"Ubuntu:26.10","package":"unbound","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["1.24.2-1ubuntu2","1.25.1-1ubuntu1","1.25.1-1ubuntu3"]},{"source":"osv","ecosystem":"Ubuntu:26.04:LTS","package":"unbound","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["1.22.0-2ubuntu2","1.22.0-2ubuntu4","1.24.2-1ubuntu1","1.24.2-1ubuntu2","1.24.2-1ubuntu2.1","1.24.2-1ubuntu2.2","1.24.2-1ubuntu2.3","1.24.2-1ubuntu2.4"]},{"source":"osv","ecosystem":"openSUSE:Tumbleweed","package":"unbound","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"1.26.2-1.1"}]}],"bundled":5}],"products":[{"vendor":"nlnet labs","product":"unbound"}],"references":[{"url":"https://www.nlnetlabs.nl/downloads/unbound/CVE-2026-35501.txt","tags":["vendor-advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-35501","tags":["web","advisory"]},{"url":"https://github.com/advisories/GHSA-mh74-9w87-h7vx"},{"url":"https://errata.tuxcare.com/els_os/rhel7els/CLSA-2026-1792810088.html","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2025-5994","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-109125","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-40622","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-50106","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-96405","tags":["advisory"]},{"url":"https://errata.tuxcare.com/els_os/oraclelinux7els/CLSA-2026-1792810562.html","tags":["advisory"]},{"url":"https://security-tracker.debian.org/tracker/CVE-2026-35501","tags":["advisory"]},{"url":"https://advisories.mageia.org/MGASA-2026-0571.html","tags":["advisory"]},{"url":"https://bugs.mageia.org/show_bug.cgi?id=36568","tags":["report"]},{"url":"https://nlnetlabs.nl/projects/unbound/security-advisories/","tags":["advisory"]},{"url":"https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2026-4732","tags":["advisory"]},{"url":"https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2026-4733","tags":["advisory"]},{"url":"https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2026-4734","tags":["advisory"]},{"url":"https://ubuntu.com/security/CVE-2026-35501","tags":["report"]},{"url":"https://www.cve.org/CVERecord?id=CVE-2026-35501","tags":["report"]},{"url":"https://community.nlnetlabs.nl/t/unbound-1-26-2-released/3495","tags":["report"]},{"url":"","tags":["advisory"]},{"url":"https://www.suse.com/security/cve/CVE-2026-109125","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-35501","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-50106","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-96405","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-97206","tags":["web"]}],"sources":{"cve":[{"id":"CVE-2026-35501","title":"Bypass of a configured island trust anchor underneath an insecure parent from an atacker-controlled NSEC record.","description":"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.","status":"published","published":"2026-10-21T08:56:55.811Z","modified":"2026-10-29T19:05:26.623Z","cvss":[{"version":"3.1","score":3.7,"vector":"CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:L/A:N","level":"low","assessor":"cna"}],"cwes":["CWE-354"],"updated_at":"2026-11-02T14:20:05.15083Z"}],"euvd":[{"id":"EUVD-2026-107151","description":"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.","status":"published","published":"2026-10-21T08:56:55Z","modified":"2026-10-29T19:05:26Z","cvss":[{"version":"3.1","score":3.7,"vector":"CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:L/A:N","level":"low"}],"updated_at":"2026-11-02T16:59:15.044173Z"}],"ghsa":[{"id":"GHSA-mh74-9w87-h7vx","title":"When NLnet Labs Unbound 1.0.1 up to and including version 1.26.1 is configured with both a root...","description":"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.","status":"published","published":"2026-10-21T09:30:30Z","modified":"2026-10-21T09:30:35Z","cvss":[{"version":"3.1","score":3.7,"vector":"CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:L/A:N","level":"low"}],"cwes":["CWE-354"],"updated_at":"2026-11-02T15:14:09.061875Z"}],"nvd":[{"id":"CVE-2026-35501","description":"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.","status":"published","published":"2026-10-21T09:17:07.373Z","modified":"2026-10-29T19:17:21.6Z","cvss":[{"version":"3.1","score":3.7,"vector":"CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:L/A:N","level":"low","assessor":"secondary"}],"cwes":["CWE-354"],"updated_at":"2026-11-02T14:13:02.045979Z"}],"osv":[{"id":"DEBIAN-CVE-2026-35501","description":"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.","status":"published","published":"2026-10-21T09:17:07.373Z","modified":"2026-10-30T09:49:10.755188774Z","cvss":[{"version":"3.1","score":3.7,"vector":"CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:L/A:N","level":"low"}],"updated_at":"2026-11-02T15:45:54.587575Z"},{"id":"OESA-2026-4732","title":"unbound security update","description":"Unbound is a validating, recursive, caching DNS resolver. It is designed to be fast and lean and incorporates modern features based on open standards. To help increase online privacy, Unbound supports DNS-over-TLS which allows clients to encrypt their communication. Unbound is available for most platforms such as FreeBSD, OpenBSD, NetBSD, MacOS, Linux and Microsoft Windows. Unbound is a totally free, open source software under the BSD license. It doesn\u0026amp;apos;t make custom builds or provide specific features to paying customers only.\r\n\r\nSecurity Fix(es):\n\nIn NLnet Labs Unbound up to and including version 1.26.1, an observable  cache-level side-channel can be exposed with \u0026apos;unwanted-reply-threshold \u0026gt; 0\u0026apos; configurations (not a default configuration). If a response-like UDP datagram reaches the upstream source port currently used by a recursive query, but its TXID does not match any pending query, Unbound counts the packet as an unwanted reply. When the accumulated count reaches the configured threshold, Unbound clears the worker\u0026apos;s RRset cache and message cache. This cache clear action does not destroy the current upstream UDP pending query. Therefore, an external observer can distinguish whether a candidate port matches the current upstream source port by checking whether an existing cached item has been cleared. This is a cache side-channel vulnerability that can be used to probe the upstream source port. Although the attack is not feasible on default configurations and the suggested value (10 million) makes it an ureliable attack on a public resolver, in scenarios where the attacker can keep a concurrent query window alive, the attacker can first filter the source port and then perform birthday-style guessing against the TXID, making cache poisoning a feasible attack path.(CVE-2026-109125)\n\nWhen 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 \u0026apos;trust-anchor:\u0026apos; 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.(CVE-2026-35501)\n\nWhen NLnet Labs Unbound up to and including version 1.26.1 is configured with both a root trust anchor and an additional \u0026apos;trust-anchor:\u0026apos; 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 \u0026apos;SignerName\u0026apos; set to the insecure parent, tricks Unbound\u0026apos;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.(CVE-2026-50106)\n\nNLnet Labs Unbound up to and including version 1.26.1 limits compression-pointer traversal for each individual domain-name operation but has no aggregate inbound decompression-work budget. Many chained compression pointers in a message results in a lot of CPU usage following them. A malicious actor with recursive-query access and control of an ordinarily delegated authority that serves specially crafted replies can exploit the vulnerability and degrade Unbound\u0026apos;s general performance.(CVE-2026-96405)","status":"published","published":"2026-11-04T13:55:02Z","modified":"2026-11-04T14:00:07.48617095Z","cvss":[{"version":"3.1","score":6.5,"vector":"CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:L/A:H","level":"medium"}],"updated_at":"2026-11-04T14:10:46.921518Z"},{"id":"OESA-2026-4733","title":"unbound security update","description":"Unbound is a validating, recursive, caching DNS resolver. It is designed to be fast and lean and incorporates modern features based on open standards. To help increase online privacy, Unbound supports DNS-over-TLS which allows clients to encrypt their communication. Unbound is available for most platforms such as FreeBSD, OpenBSD, NetBSD, MacOS, Linux and Microsoft Windows. Unbound is a totally free, open source software under the BSD license. It doesn\u0026amp;apos;t make custom builds or provide specific features to paying customers only.\r\n\r\nSecurity Fix(es):\n\nIn NLnet Labs Unbound up to and including version 1.26.1, an observable  cache-level side-channel can be exposed with \u0026apos;unwanted-reply-threshold \u0026gt; 0\u0026apos; configurations (not a default configuration). If a response-like UDP datagram reaches the upstream source port currently used by a recursive query, but its TXID does not match any pending query, Unbound counts the packet as an unwanted reply. When the accumulated count reaches the configured threshold, Unbound clears the worker\u0026apos;s RRset cache and message cache. This cache clear action does not destroy the current upstream UDP pending query. Therefore, an external observer can distinguish whether a candidate port matches the current upstream source port by checking whether an existing cached item has been cleared. This is a cache side-channel vulnerability that can be used to probe the upstream source port. Although the attack is not feasible on default configurations and the suggested value (10 million) makes it an ureliable attack on a public resolver, in scenarios where the attacker can keep a concurrent query window alive, the attacker can first filter the source port and then perform birthday-style guessing against the TXID, making cache poisoning a feasible attack path.(CVE-2026-109125)\n\nWhen 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 \u0026apos;trust-anchor:\u0026apos; 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.(CVE-2026-35501)\n\nWhen NLnet Labs Unbound up to and including version 1.26.1 is configured with both a root trust anchor and an additional \u0026apos;trust-anchor:\u0026apos; 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 \u0026apos;SignerName\u0026apos; set to the insecure parent, tricks Unbound\u0026apos;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.(CVE-2026-50106)\n\nNLnet Labs Unbound up to and including version 1.26.1 limits compression-pointer traversal for each individual domain-name operation but has no aggregate inbound decompression-work budget. Many chained compression pointers in a message results in a lot of CPU usage following them. A malicious actor with recursive-query access and control of an ordinarily delegated authority that serves specially crafted replies can exploit the vulnerability and degrade Unbound\u0026apos;s general performance.(CVE-2026-96405)","status":"published","published":"2026-11-04T13:55:02Z","modified":"2026-11-04T14:00:07.833001382Z","cvss":[{"version":"3.1","score":6.5,"vector":"CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:L/A:H","level":"medium"}],"updated_at":"2026-11-04T14:10:46.921518Z"},{"id":"OESA-2026-4734","title":"unbound security update","description":"Unbound is a validating, recursive, caching DNS resolver. It is designed to be fast and lean and incorporates modern features based on open standards. To help increase online privacy, Unbound supports DNS-over-TLS which allows clients to encrypt their communication. Unbound is available for most platforms such as FreeBSD, OpenBSD, NetBSD, MacOS, Linux and Microsoft Windows. Unbound is a totally free, open source software under the BSD license. It doesn\u0026amp;apos;t make custom builds or provide specific features to paying customers only.\r\n\r\nSecurity Fix(es):\n\nIn NLnet Labs Unbound up to and including version 1.26.1, an observable  cache-level side-channel can be exposed with \u0026apos;unwanted-reply-threshold \u0026gt; 0\u0026apos; configurations (not a default configuration). If a response-like UDP datagram reaches the upstream source port currently used by a recursive query, but its TXID does not match any pending query, Unbound counts the packet as an unwanted reply. When the accumulated count reaches the configured threshold, Unbound clears the worker\u0026apos;s RRset cache and message cache. This cache clear action does not destroy the current upstream UDP pending query. Therefore, an external observer can distinguish whether a candidate port matches the current upstream source port by checking whether an existing cached item has been cleared. This is a cache side-channel vulnerability that can be used to probe the upstream source port. Although the attack is not feasible on default configurations and the suggested value (10 million) makes it an ureliable attack on a public resolver, in scenarios where the attacker can keep a concurrent query window alive, the attacker can first filter the source port and then perform birthday-style guessing against the TXID, making cache poisoning a feasible attack path.(CVE-2026-109125)\n\nWhen 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 \u0026apos;trust-anchor:\u0026apos; 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.(CVE-2026-35501)\n\nWhen NLnet Labs Unbound up to and including version 1.26.1 is configured with both a root trust anchor and an additional \u0026apos;trust-anchor:\u0026apos; 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 \u0026apos;SignerName\u0026apos; set to the insecure parent, tricks Unbound\u0026apos;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.(CVE-2026-50106)\n\nNLnet Labs Unbound up to and including version 1.26.1 limits compression-pointer traversal for each individual domain-name operation but has no aggregate inbound decompression-work budget. Many chained compression pointers in a message results in a lot of CPU usage following them. A malicious actor with recursive-query access and control of an ordinarily delegated authority that serves specially crafted replies can exploit the vulnerability and degrade Unbound\u0026apos;s general performance.(CVE-2026-96405)","status":"published","published":"2026-11-04T13:55:03Z","modified":"2026-11-04T14:00:07.936178531Z","cvss":[{"version":"3.1","score":6.5,"vector":"CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:L/A:H","level":"medium"}],"updated_at":"2026-11-04T14:10:46.921518Z"},{"id":"UBUNTU-CVE-2026-35501","description":"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.","status":"published","published":"2026-10-21T09:17:00Z","modified":"2026-10-28T20:17:47.314813774Z","cvss":[{"version":"3.1","score":3.7,"vector":"CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:L/A:N","level":"low"}],"updated_at":"2026-11-02T16:56:16.686388Z"},{"id":"AZL-109821","title":"CVE-2026-35501 affecting package unbound for versions less than 1.26.2-1","description":"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.","status":"published","published":"2026-10-21T09:17:07Z","modified":"2026-11-06T14:16:53.514952068Z","updated_at":"2026-11-06T14:57:15.495576Z"},{"id":"CLSA-2026-1792810088","title":"unbound: Fix of 6 CVEs","description":"- CVE-2025-5994: do not cache non-ECS answers to ECS queries in the subnet cache (Rebirthday attack)\n- CVE-2026-40622: limit the TTL of a higher-trust NS rrset replacing a cached delegation (ghost domain)\n- CVE-2026-50106: treat an unsigned parent denial of an island trust anchor as bogus\n- CVE-2026-96405: add a per-packet budget for name decompression pointers\n- CVE-2026-109125: clear pending queries on a port when the unwanted-reply threshold is hit\n- CVE-2026-35501: fix NSEC-not-at-apex parent-side key lookup for island trust anchors","status":"published","published":"2026-10-24T02:48:24Z","modified":"2026-10-26T09:43:45.650812372Z","updated_at":"2026-11-02T15:43:54.981307Z"},{"id":"CLSA-2026-1792810562","title":"unbound: Fix of 6 CVEs","description":"- CVE-2025-5994: do not cache non-ECS answers to ECS queries in the subnet cache (Rebirthday attack)\n- CVE-2026-40622: limit the TTL of a higher-trust NS rrset replacing a cached delegation (ghost domain)\n- CVE-2026-50106: treat an unsigned parent denial of an island trust anchor as bogus\n- CVE-2026-96405: add a per-packet budget for name decompression pointers\n- CVE-2026-109125: clear pending queries on a port when the unwanted-reply threshold is hit\n- CVE-2026-35501: fix NSEC-not-at-apex parent-side key lookup for island trust anchors","status":"published","published":"2026-10-24T02:56:17Z","modified":"2026-10-26T09:43:42.33157517Z","updated_at":"2026-11-02T15:43:54.981307Z"},{"id":"MGASA-2026-0571","title":"Updated unbound package fixes security vulnerabilities","description":"Bypass of a configured island trust anchor underneath an insecure parent\nfrom an attacker-controlled NSEC record.\nPossible insecure NXDOMAIN for non-existing records under a configured\nisland trust anchor underneath an insecure parent.\nAggregate DNS name chained pointer decompression work leads to\ndegradation of service.\nDNS-over-QUIC path-migration can lead to use-after-free on\nmulti-threaded deployments.\nPossible cache poisoning vulnerability via a cache side-channel exposed\nby 'unwanted-reply-threshold'.\n","status":"published","published":"2026-11-02T16:03:56Z","modified":"2026-11-02T16:27:56.070550968Z","updated_at":"2026-11-02T16:43:25.26575Z"},{"id":"openSUSE-SU-2026:12257-1","title":"libunbound8-1.26.2-1.1 on GA media","description":"These are all security issues fixed in the libunbound8-1.26.2-1.1 package on the GA media of openSUSE Tumbleweed.","status":"published","published":"2026-10-23T00:00:00Z","modified":"2026-10-24T17:23:12.829074157Z","updated_at":"2026-11-02T16:58:40.245664Z"}]}}