Source: unbound
Version: 1.25.0-1
Severity: grave
Tags: security upstream
Justification: user security hole
X-Debbugs-Cc: [email protected], Debian Security Team <[email protected]>
Hi,
The following vulnerabilities were published for unbound.
CVE-2026-32792[0]:
| NLnet Labs Unbound 1.6.2 up to and including version 1.25.0 has a
| denial of service vulnerability when compiled with DNSCrypt support
| ('--enable-dnscrypt'). A bad DNSCrypt query could underflow
| Unbound's DNSCrypt packet reading procedure that may lead to heap
| overflow. A malicious actor can exploit the vulnerability with a
| single bad DNSCrypt query that its decrypted plaintext consists
| entirely of '0x00' bytes and does not contain the expected '0x80'
| marker. Unbound would then start reading more bytes than necessary
| until it finds a non-'0x00' byte. Based on the underlying memory
| allocator and the memory layout, it could lead to heap overflow
| while reading followed by a crash. Likelihood of a crash is low,
| since it relies heavily on the underlying memory allocator and the
| memory layout. If the heap overflow does not happen, Unbound's later
| packet checks will deny the packet. Unbound 1.25.1 contains a patch
| with a fix to bound reading in the given buffer space.
CVE-2026-33278[1]:
| NLnet Labs Unbound 1.19.1 up to and including version 1.25.0 has a
| vulnerability in the DNSSEC validator that enables denial of service
| and possible remote code execution as a result of deep copying a
| data structure and erroneously overwriting a destination pointer. An
| adversary can exploit the vulnerability by controlling a malicious
| signed zone and querying a vulnerable Unbound. When DS sub-queries
| need to suspend validation due to NSEC3 computational budget
| exhaustion (introduced in Unbound 1.19.1), Unbound deep-copies
| response messages to preserve them across memory region teardown. A
| struct-assignment bug overwrites the destination's pointer with the
| source's pointer. After the sub-query region is freed, the resumed
| validator dereferences this dangling pointer, triggering a crash or
| potentially enabling arbitrary code execution. Unbound 1.25.1
| contains a patch with a fix to preserve the correct pointer when
| deep copying the data structure.
CVE-2026-40622[2]:
| NLnet Labs Unbound 1.16.2 up to and including version 1.25.0 has a
| vulnerability of the 'ghost domain names' family of attacks that
| could extend the ghost domain window by up to one cached TTL
| configured value. Similar to other 'ghost domain names' attacks, an
| adversary needs to control a (ghost) zone and be able to query a
| vulnerable Unbound. A single client NS query can cause Unbound to
| overwrite the cached expired parent-side referral NS rrset with the
| child-side apex NS rrset and essentially extend the ghost domain
| window by up to one cached TTL configured value ('cache-max-ttl').
| In configurations where 'harden-referral-path: yes' is used (non-
| default configuration), no client NS query is required since Unbound
| implicitly performs that query. Unbound 1.25.1 contains a patch with
| a fix that does not allow extension of TTLs for (parent) NS records
| regardless of their trust.
CVE-2026-41292[3]:
| NLnet Labs Unbound up to and including version 1.25.0 is vulnerable
| to a degradation of service attack related to parsing long lists of
| incoming EDNS options. An adversary sending queries with too many
| EDNS options can hold Unbound threads hostage while they are parsing
| and creating internal data structures for the options. Coordinated
| attacks can result in degradation and/or denial of service. Unbound
| 1.25.1 contains a patch with a fix to limit acceptable incoming EDNS
| options (100).
CVE-2026-42534[4]:
| NLnet Labs Unbound up to and including version 1.25.0 has a
| vulnerability in the jostle logic that could defeat its purpose and
| degrade resolution performance. Retransmits of the same query could
| renew the age of slow running queries and not allow the jostle logic
| to see them as aged and potential targets for replacement with new
| queries. An adversary who can query a vulnerable Unbound and who can
| control a domain name server that replies slowly and/or maliciously
| to Unbound's queries can exploit the vulnerability and degrade the
| resolution performance of Unbound. When Unbound's 'num-queries-per-
| thread' reaches its limit, the jostle logic kicks in. When a new
| query comes in, half of the available queries that are also slow to
| resolve are candidates for replacement. The vulnerability then
| happens because duplicate queries that need resolution would skew
| the aging result by using the timestamp of the latest duplicate
| query instead of the original one that started the resolution
| effort. Cache and local data response performance remains
| unaffected. Coordinated attacks could raise this to a denial of
| resolution service. Unbound 1.25.1 contains a patch with a fix to
| attach an initial, non-updatable start time for incoming queries
| that allow the jostle logic to work as intended.
CVE-2026-42923[5]:
| NLnet Labs Unbound up to and including version 1.25.0 has a
| vulnerability in the DNSSEC validator where the code path to consult
| the negative cache for DS records does not take into account the
| limit on NSEC3 hash calculations introduced in 1.19.1. This leads to
| degradation of service during the attack. An adversary that controls
| a DNSSEC signed zone can exploit this by signing NSEC3 records with
| acceptably high iterations for child delegations and querying a
| vulnerable Unbound. Unbound will keep performing the allowed hash
| calculations on the NSEC3 records and will not limit the work by the
| mitigation introduced in 1.19.1. As a side effect, a global lock for
| the negative cache will be held for the duration of the hashing,
| blocking other threads that need to consult the negative cache.
| Coordinated attacks could raise the vulnerability to denial of
| service. Unbound 1.25.1 contains a patch with a fix to bound the
| vulnerable code path with the existing limit for NSEC3 hash
| calculations.
CVE-2026-42944[6]:
| NLnet Labs Unbound 1.14.0 up to and including version 1.25.0 has a
| vulnerability that results in heap overflow when encoding multiple
| NSID and/or DNS Cookie EDNS and/or EDNS Padding options in the reply
| packet. The relevant options ('nsid', 'answer-cookie', 'pad-
| responses' (default)) need to be enabled for the vulnerability to be
| exploited. An adversary who can query Unbound can exploit the
| vulnerability by attaching multiple NSID and/or DNS Cookie EDNS
| and/or EDNS Padding options to the query. A flaw in the size
| calculation of the EDNS field truncates the correct value which
| allows the encoder to overflow the available space when writing.
| Those two combined lead to a heap overflow write of Unbound
| controlled data and eventually a crash. Unbound 1.25.1 contains a
| patch with a fix to de-duplicate the EDNS options and a fix to
| prevent truncation of the EDNS field size calculation.
CVE-2026-42959[7]:
| NLnet Labs Unbound up to and including version 1.25.0 has a denial
| of service vulnerability in the DNSSEC validator that can lead to a
| crash given malicious upstream replies. When Unbound constructs
| chase-reply messages for validation, the code uses the wrong counter
| to calculate write offsets for ADDITIONAL section rrsets. DNAME
| duplication could increase the ANSWER section count and authority
| filtering could decrease the AUTHORITY section count and create an
| uninitialized array slot. Combining these two, the validator later
| dereferences this uninitialized pointer, causing an immediate
| process crash. An adversary controlling a DNSSEC-signed domain can
| trigger this bug with a single query by configuring a DNAME chain
| with unsigned CNAMEs and a response containing unsigned AUTHORITY
| records alongside signed ADDITIONAL glue records. Unbound 1.25.1
| contains a patch with a fix to use the proper counters to calculate
| the write offsets.
CVE-2026-42960[8]:
| NLnet Labs Unbound up to and including version 1.25.0 is vulnerable
| to poisoning via promiscuous records for the authority section.
| Promiscuous RRSets that complement DNS replies in the authority
| section can be used to trick Unbound to cache such records. If an
| adversary is able to attach such records in a reply (i.e., spoofed
| packet, fragmentation attack) he would be able to poison Unbound's
| cache. A malicious actor can exploit the possible poisonous effect
| by injecting RRSets other than NS that are also accompanied by
| address records in a reply, for example MX. This could be achieved
| by trying to spoof a reply packet or fragmentation attacks. Unbound
| would then accept the relative address records in the additional
| section and cache them if the authority RRSet has enough trust at
| this point, i.e., in-zone data for the delegation point. Unbound
| 1.25.1 contains a patch with a fix that disregards address records
| from the additional section if they are not explicitly relevant only
| to authority NS records, mitigating the possible poison effect. This
| is a complement fix to CVE-2025-11411.
CVE-2026-44390[9]:
| NLnet Labs Unbound up to and including version 1.25.0 has a
| vulnerability when handling replies with very large RRsets that
| Unbound needs to perform name compression for. Malicious upstream
| responses with very large RRsets with records that don't share a
| suffix above the root can cause Unbound to spend a considerable time
| applying name compression to downstream replies. This can lead to
| degraded performance and eventually denial of service in well
| orchestrated attacks. An adversary can exploit the vulnerability by
| querying Unbound for the specially crafted contents of a malicious
| zone with very large RRsets. Before Unbound replies to the query it
| will try to apply name compression which was an unbounded operation
| that could lock the CPU until the whole packet was complete. A
| compression limit was introduced in 1.21.1 for this but it didn't
| account for the case where records would not share any suffix above
| the root. That causes Unbound to go in a different code path because
| of the compression tree lookup failure and eventually not increment
| the compression counter for those operations. Unbound 1.25.1
| contains a patch with a fix that increments the compression counter
| regardless of the compression tree lookup. This is a complement fix
| to CVE-2024-8508.
CVE-2026-44608[10]:
| NLnet Labs Unbound 1.14.0 up to and including version 1.25.0 has a
| locking inconsistency vulnerability that when certain conditions are
| met (multi-threaded, RPZ XFR reload, RPZ zone with 'rpz-nsip'/'rpz-
| nsdname' triggers) it could result in heap use-after-free and
| eventual crash. An adversary can exploit the vulnerability if
| conditions are first met on a vulnerable Unbound, i.e., multi-
| threaded, an RPZ zone with 'rpz-nsip'/'rpz-nsdname' triggers and an
| ongoing XFR for that RPZ zone. Local RPZ files do not trigger the
| vulnerability. If the timing is right and an XFR happens at the same
| time another thread needs to read that RPZ zone, the reader may not
| hold the lock long enough and the thread applying the XFR may free
| objects that the reader is about to walk causing the use-after-free.
| Unbound 1.25.1 contains a patch with a fix to the locking code.
If you fix the vulnerabilities please also make sure to include the
CVE (Common Vulnerabilities & Exposures) ids in your changelog entry.
For further information see:
[0] https://security-tracker.debian.org/tracker/CVE-2026-32792
https://www.cve.org/CVERecord?id=CVE-2026-32792
[1] https://security-tracker.debian.org/tracker/CVE-2026-33278
https://www.cve.org/CVERecord?id=CVE-2026-33278
[2] https://security-tracker.debian.org/tracker/CVE-2026-40622
https://www.cve.org/CVERecord?id=CVE-2026-40622
[3] https://security-tracker.debian.org/tracker/CVE-2026-41292
https://www.cve.org/CVERecord?id=CVE-2026-41292
[4] https://security-tracker.debian.org/tracker/CVE-2026-42534
https://www.cve.org/CVERecord?id=CVE-2026-42534
[5] https://security-tracker.debian.org/tracker/CVE-2026-42923
https://www.cve.org/CVERecord?id=CVE-2026-42923
[6] https://security-tracker.debian.org/tracker/CVE-2026-42944
https://www.cve.org/CVERecord?id=CVE-2026-42944
[7] https://security-tracker.debian.org/tracker/CVE-2026-42959
https://www.cve.org/CVERecord?id=CVE-2026-42959
[8] https://security-tracker.debian.org/tracker/CVE-2026-42960
https://www.cve.org/CVERecord?id=CVE-2026-42960
[9] https://security-tracker.debian.org/tracker/CVE-2026-44390
https://www.cve.org/CVERecord?id=CVE-2026-44390
[10] https://security-tracker.debian.org/tracker/CVE-2026-44608
https://www.cve.org/CVERecord?id=CVE-2026-44608
[11] https://www.openwall.com/lists/oss-security/2026/05/20/5
Regards,
Salvatore
