UNBOUND

Remote DNS-over-QUIC denial of service due to 'quic-size' budget bypass

When downstream DNS-over-QUIC (DoQ) is enabled, Unbound documents the quic-size configuration option as the maximum number of bytes for all QUIC buffers and data combined, and states that new connections or streams should be refused/reset once the limit is exceeded. However, an improper validation of the client provided length could allow over allocating memory and trivially exceeding the configured budget for future DoQ connections leading to denial of service for new DoQ clients.

When downstream DNS-over-QUIC (DoQ) is enabled, the first two bidirectional streams on a new QUIC connection (stream_id 0 and 4) bypass the per-stream quic-size gate entirely, and large input buffers are allocated later, after only the 2-byte length prefix has been received from the initial streams.

As a result, a remote client can make Unbound exceed the configured quic-size limit with low-cost input. Using only one connection and two streams, each sending a declared 65535-byte length prefix and then holding the streams open, a client can already trivially make Unbound roughly allocate double that amount.

This is a remote availability issue / memory-accounting bypass in the downstream DoQ implementation that leads to denial of service for new DoQ clients.

This vulnerability needs Unbound to be compiled with DoQ support (--with-libngtcp2) and the quic-port to be configured for the listening interfaces.

Unbound 1.25.2 includes a fix to properly budget QUIC streams against the quic-size configuration disallowing clients to over allocate memory.

If you cannot upgrade you can apply the patch manually on the Unbound source directory with patch -p1 < patch_CVE-2026-32665.diff.

This is part of the 1.25.2 security release containing multiple fixes. The combined patch can be applied INSTEAD to address all of them. A minimal version also exists for easier patching.

Packet of death for DNSCrypt over TCP

A denial of service vulnerability has been discovered in Unbound when compiled with DNSCrypt support (--enable-dnscrypt). A single bad DNSCrypt query over TCP could underflow Unbound's DNSCrypt packet reading procedure that may lead to heap overflow and eventual server crash and denial of service.

When a DNSCrypt query is received over TCP, the routine that encrypts the reply in place fails to bound the reply length against the destination buffer size. The size clamp that protects the UDP path is not applied on the TCP path, so a reply larger than 65504 bytes is shifted forward by 48 bytes inside a buffer of capacity equal to msg-buffer-size, writing past the end of the heap allocation. A single malicious encrypted query crashes the resolver and lead to denial of service.

This vulnerability needs Unbound to be compiled with DNSCrypt support (--enable-dnscrypt) and the dnscrypt: clause to be configured and enabled for the listening interfaces.

Unbound 1.25.2 includes fixes to select the proper buffer TCP buffer for DNSCrypt, to properly check against the buffer's capacity and to clear the buffer before writing the dnscrypt contents otherwise UDP queries can hit assertions.

There are two patches available that address the issue:

• minimal patch,
• complete patch (accompanying code improvements/tests)

If you cannot upgrade you can apply EITHER of the above patches manually on the Unbound source directory with patch -p1 < patch_CVE-2026-40691.diff.

This is part of the 1.25.2 security release containing multiple fixes. The combined patch can be applied INSTEAD to address all of them. A minimal version also exists for easier patching.

Cross-zone wildcard cache poisoning via RRSIG.labels manipulation

Insufficient validation of the RRSIG.Labels field combined with premature cache writes during RFC 8198 aggressive NSEC processing leads to cache poisoning that permits a malicious actor controlling a single delegated zone to poison arbitrary sibling zones under NSEC-signed parent domains.

A malicious actor with one registered domain under an NSEC-signed TLD can serve malicious insecure DNS responses for unrelated sibling domains (sharing the same parent zone). Arbitrary delegations that do not exist under the parent domain and are covered by the parent's NSEC chain can be brought into insecure existence by fraudulent wildcard DS records (less labels than expected, unknown algorithm) from the malicious sibling domain. This allows the malicious actor to inject insecure wildcard records for those delegations.

Unbound 1.25.2 includes fixes to add lower-bound check in RRSIG labels, move cache write stricly after validation and adding bailiwick check when updating wildcards.

If you cannot upgrade you can apply the patch manually on the Unbound source directory with patch -p1 < patch_CVE-2026-44690.diff.

This is part of the 1.25.2 security release containing multiple fixes. The combined patch can be applied INSTEAD to address all of them. A minimal version also exists for easier patching.

'dns-error-reporting: yes' leads to stack buffer overflow

When dns-error-reporting: yes is set, the EDNS Report-Channel option (code 18) from the last upstream response is read and uses the option's length as the length of the agent domain. When a domain name check is performed on the agent domain, the returned lenght is not used and if the agent domain is followed by garbage, those bytes are moved onto the tail of the synthetic '_er.' report query name.

That query name is later used in the iterator via a subquery to send out the DNS Error Report and when Unbound tries to walk that query name during find_closest_of_type(), it strips labels using the query name length rather than stopping at the embedded root, walks one byte past it, and feeds the first garbage byte to dname_query_hash() as a label length writing over the stack variable labuf.

One ordinary upstream response from a delegated zone the attacker controls is sufficient to terminate the daemon.

Unbound 1.25.2 includes a fix to use the proper length of the agent domain name instead of the EDNS option lenght one.

If you cannot upgrade you can apply the patch manually on the Unbound source directory with patch -p1 < patch_CVE-2026-55973.diff.

This is part of the 1.25.2 security release containing multiple fixes. The combined patch can be applied INSTEAD to address all of them. A minimal version also exists for easier patching.

Assertion in libngtcp2 when under pressure in high concurrency DNS-over-QUIC environments

In DNS-over-QUIC environments, with high concurrency and under pressure, an assertion in libngtcp2 about monotonic timestamps could trigger and result in server termination and thus denial of service.

When interfacing with libngtcp2, for DNS-over-QUIC support in Unbound, it is expected to use monotonic time. Unbound was using realtime instead, and in DoQ environments with high concurrency and under pressure, an assert in libngtcp2 for the quic timestamp would trigger and terminate the server.

This vulnerability needs Unbound to be compiled with DoQ support (--with-libngtcp2) and the quic-port to be configured for the listening interfaces.

Unbound 1.25.2 includes a fix that explicitly uses monotonic time when interfacing with libngtcp2.

If you cannot upgrade you can apply the patch manually on the Unbound source directory with patch -p1 < patch_CVE-2026-14586.diff.

This is part of the 1.25.2 security release containing multiple fixes. The combined patch can be applied INSTEAD to address all of them. A minimal version also exists for easier patching.

Libunbound applications configured with 'unwanted-reply-threshold' could eventually be abruptly terminated

Applications using libunbound and configured with unwanted-reply-threshold, could eventually be abruptly terminated if the threshold is reached and libunbound needs to call libworker_alloc_cleanup since the function is absent from the function call allow list.

When an application using libunbound sets unwanted-reply-threshold to any non-zero value and the iterator queries an authoritative that replies with enough wrong-transaction-ID UDP datagrams to cross the threshold, the libworker_alloc_cleanup will eventually be called. Since the function is absent from the function call allow list, this leads to a fatal exit of libunbound and eventual termination of the embedding application.

Unbound itself is not affected since its relevant function worker_alloc_cleanup is registed in the allow list and proceeds to perform the documented cache flush.

Unbound 1.25.2 includes a fix to include the libworker_alloc_cleanup function in the allow list of function calls.

There are two patches available that address the issue:

• minimal patch,
• complete patch (accompanying code improvements/tests)

If you cannot upgrade you can apply EITHER of the above patches manually on the Unbound source directory with patch -p1 < patch_CVE-2026-44621.diff.

This is part of the 1.25.2 security release containing multiple fixes. The combined patch can be applied INSTEAD to address all of them. A minimal version also exists for easier patching.

'max-global-quota' reset by DNSSEC validation restarts

A single client query for a deeply nested name under a DNSSEC-signed parent can cause Unbound to send more upstream packets per client query than the configured max-global-quota.

This effectively bypasses a security configuration that limits upstream amplification traffic.

Unbound 1.25.2 includes a fix to continue counting the global quota counter across validator subqueries and also for validator query lookup restarts.

If you cannot upgrade you can apply the patch manually on the Unbound source directory with patch -p1 < patch_CVE-2026-50045.diff.

This is part of the 1.25.2 security release containing multiple fixes. The combined patch can be applied INSTEAD to address all of them. A minimal version also exists for easier patching.

Possible heap use-after-free in an error path when a DoT forwarded query is jostled out

The TLS server name used for DNS-over-TLS (DoT) forwarded queries is tied to a struct's (serviced_query) lifetime but also referenced by another struct (waiting_tcp). When the owning struct is jostled out of the mesh while the DoT TCP stream is still handshaking it frees the storage behind the referenced string and if the TLS stream then errors out, it dereferences the freed pointer. The dereference is read-only and the practical impact is a daemon crash resulting in denial of service.

A malicious actor that knows a DoT forwarding/stub Unbound's configuration could exploit the vulnerability by quering records in the appropriate zone while keeping Unbound uder pressure so that the jostle logic kicks in. If answers for the vulnerable zone are slow, the likelihood of jostling such queries is higher, although the timing of the jostle needs to be precise.

Requirements for a vulnerable Unbound is the existence of a stub/forward zone configured for DoT together with a configured #authname suffix on the server identification. The connectivity to the server needs to exhibit a transient failure at the correct time in order to kick off the vulnerable error path.

Unbound 1.25.2 includes a fix to own (copy) the TLS server name solving the lifetime issue on error paths.

If you cannot upgrade you can apply the patch manually on the Unbound source directory with patch -p1 < patch_CVE-2026-50046.diff.

This is part of the 1.25.2 security release containing multiple fixes. The combined patch can be applied INSTEAD to address all of them. A minimal version also exists for easier patching.

'response-ip'/'rpz' can rewrite BOGUS answers instead of returning SERVFAIL

When Unbound is configured with the respip module in front of the validator together with a response-ip redirect rule or an RPZ file with an RPZ-IP trigger, the rewriting handler does not check the security status of the upstream answer and can instead rewrite a BOGUS A/AAAA answer to point to an operator's configured IP.

If the validator finds an expired or otherwise invalid RRSIG on an answer whose A record falls within a response-ip/RPZ configuration, the answer is still rewritten and given a hard coded security level of INSECURE. This results in the client receiving an INSECURE NOERROR reply rewritten by the operator's configured IP.

A malicious actor can exploit the possible poisonous effect by spoofing a BOGUS A/AAAA answer that falls inside the operator's configured subnet rewrites. Such DNSSEC protected answers are then insecurely redirected to the operator's configured target.

Unbound 1.25.2 includes a fix to ensure that response-ip/RPZ-IP rewrite logic does not process BOGUS answers.

If you cannot upgrade you can apply the patch manually on the Unbound source directory with patch -p1 < patch_CVE-2026-50243.diff.

This is part of the 1.25.2 security release containing multiple fixes. The combined patch can be applied INSTEAD to address all of them. A minimal version also exists for easier patching.

BOGUS configured primary hostname accepted for XFR in auth/rpz zones

When an auth/rpz zone has a configured primary hostname that resolves to BOGUS A/AAAA, it is still considered as a possible XFR endpoint.

A malicious actor that can spoof the hostname's A/AAAA record (no valid RRSIG required) becomes the zone's XFR primary and can replaces the entire zone/the resolver's entire response policy.

Unbound 1.25.2 includes a fix to disregard BOGUS configured primary hostnames for XFR endpoints in auth/rpz zones.

If you cannot upgrade you can apply the patch manually on the Unbound source directory with patch -p1 < patch_CVE-2026-50248.diff.

This is part of the 1.25.2 security release containing multiple fixes. The combined patch can be applied INSTEAD to address all of them. A minimal version also exists for easier patching.

Attacker supplied '0.0.0.0'/'::' glue triggers defensive full-cache flush

When unwanted-reply-threshold is enabled (set to any value greater than zero), glue records of 0.0.0.0/::0 can short-circuit Unbound, on systems that can direct such traffic, by issuing DNS queries and receiving seemingly unwanted replies since the remote IP does not match the original source IP of 0.0.0.0/::0. This behavior keeps on looping for the glue records and pushing the counter to the configured unwanted-reply-threshold that triggers a defensive cache clear.

A malicious actor who controls a delegation that returns in-bailiwick glue of 0.0.0.0/::0 can drive the counter to the limit of unwanted-reply-threshold to the threshold and trigger a cache clean of the message and rrset caches; at will, indefinitely, without sending a single spoofed packet.

The iterator uses the 0.0.0.0/::0 glue, and a system that can route this (e.g., Linux kernel routes the datagram over loopback), Unbound's own listener answers from 127.0.0.1. Because of the mismatch of 0.0.0.0 and 127.0.0.1, in this example, Unbound accounts the reply as an unwanted (probably spoofed) answer. The counter resets to zero on every cache flush, so the attack loops forever.

Unbound 1.25.2 includes a fix to that implicitly adds 0.0.0.0/::0 to the do-not-query-address by default.

There are two patches available that address the issue:

• minimal patch,
• complete patch (accompanying code improvements/tests)

If you cannot upgrade you can apply EITHER of the above patches manually on the Unbound source directory with patch -p1 < patch_CVE-2026-50251.diff.

This is part of the 1.25.2 security release containing multiple fixes. The combined patch can be applied INSTEAD to address all of them. A minimal version also exists for easier patching.

Possible cache poisoning attack by mapping source port population per thread

UDP source port is randomized and intended to serve as a secret value that increases the entropy of DNS transactions. When resolver load balancing policies depend on the source port while their outcome is revealed this secrecy is undermined. The vulnerability arises when the load balancing policy is consistent with respect to the incoming source UDP port and IP address while heavily depending on the incoming source UDP port as a randomization source. When the SO_REUSEPORT configuration option is enabled (so-reuseport: yes) in Unbound (by default), it meets these conditions, making it vulnerable for DNS cache poisoning attacks.

Upon startup, Unbound randomly partitions the available UDP source port space into disjoint subsets of (almost) equal size, assigning each subset to a specific worker thread. When an incoming DNS query is received, the kernel’s SO_REUSEPORT load balancing mechanism deterministically assigns the query to a socket associated with a particular thread. All outgoing DNS queries generated during the resolution of that request use source ports selected exclusively from the port subset assigned to the corresponding thread. Since these port subsets are disjoint across threads, the source port observed in a resolver’s outgoing query to an authoritative name server serves as a reliable indicator of the worker thread that processed the original client query.

A malicious actor can acquire the mapping between incoming UDP source ports (for a given fixed source IP address) and Unbound worker threads and leverage it to conduct DNS cache poisoning attacks by effectively lowering the random port population per thread.

Unbound 1.25.2 includes a fix that makes a shared ports structure, with all available ports per interface that the threads can then pick up a port number from.

There are two patches available that address the issue:

• minimal patch,
• complete patch (accompanying code improvements/tests)

If you cannot upgrade you can apply EITHER of the above patches manually on the Unbound source directory with patch -p1 < patch_CVE-2026-50252.diff.

This is part of the 1.25.2 security release containing multiple fixes. The combined patch can be applied INSTEAD to address all of them. A minimal version also exists for easier patching.

Memory corruption could lead to crash and denial of service

A fix in 1.25.0 that makes the respip and dns64 modules work together, creates a shallow copy of the view name in effect that could lead to memory corruption if the owner of the original view name is jostled out when Unbound is under pressure.

Unbound needs to be configured with one of respip/rpz modules, together with a module that can attach subqueries (respip CNAME redirection, dns64, subnetcache) and a configured access-control-view while Unbound is under pressure so that joslte logic kicks in and starts dropping slow queries. The subquery is getting a shallow copy of the view name and if the super query which owns the view name is jostled out, memory corruption can occur. Likelihood of a crash is low, since it relies heavily on the underlying memory allocator and the memory layout. Debug memory builds (e.g., ASAN) that catch the free terminate the server.

Unbound 1.25.2 includes a fix to properly copy the required view name.

There are two patches available that address the issue:

• minimal patch,
• complete patch (accompanying code improvements/tests)

If you cannot upgrade you can apply EITHER of the above patches manually on the Unbound source directory with patch -p1 < patch_CVE-2026-52863.diff.

This is part of the 1.25.2 security release containing multiple fixes. The combined patch can be applied INSTEAD to address all of them. A minimal version also exists for easier patching.

'serve-expired-client-timeout' and 'response-ip' CNAME redirect could lead to a crash

When serve-expired: yes is set together with a response-ip: <net> redirect /response-ip-data: <net> CNAME <target> rule (or the RPZ rpz-cname-override equivalent), a remote client who controls any delegated domain can crash the daemon. The serve-expired-client-timeout callback runs a two-pass loop to chase the respip-generated CNAME alias; on the second pass it resets alias_rrset but not partial_rep. Later, this inconsistency leads to a NULL pointer dereference and an eventual crash.

A malicious actor can exploit the vulnerability by controlling any zone that replies with an A/AAAA record that falls inside the configured response-ip/rpz subnet. By delaying the answer when the previous record has expired, the vulnerable path of serve-expired-client-timeout is taken leading to denial of service via the server crash.

Unbound 1.25.2 includes a fix to correctly set the partial reply to NULL as well after the merge on the second loop iteration.

If you cannot upgrade you can apply the patch manually on the Unbound source directory with patch -p1 < patch_CVE-2026-55717.diff.

This is part of the 1.25.2 security release containing multiple fixes. The combined patch can be applied INSTEAD to address all of them. A minimal version also exists for easier patching.

Packet of death for a DNSCrypt misconfigured Unbound

When the dnscrypt: clause lists more dnscrypt-provider-cert: files than there are matching dnscrypt-secret-key: files, Unbound fills only the matched prefix and leaves the tail slots at the 0xdb fill that libsodium's allocator writes into every allocation. Unbound would then iterate over the number of cert files, not the actual slots, so it walks into a slot with garbage data filled with 0xdb bytes. Any unauthenticated client that sends one UDP datagram of ≥ 68 bytes whose first 8 bytes are 0xdb to dnscrypt-port will use that garbage entry which leads to a garbage dereference killing the server.

This is a silent faulty configuration that goes unnoticed until triggered with the right client query.

Unbound needs to be compiled with DNSCrypt support (--enable-dnscrypt).

Unbound 1.25.2 includes a fix to fail fast on such faulty configuration and an in-depth-fix to zero out the certificate array and skip NULL keypairs.

If you cannot upgrade you can apply the patch manually on the Unbound source directory with patch -p1 < patch_CVE-2026-55990.diff.

This is part of the 1.25.2 security release containing multiple fixes. The combined patch can be applied INSTEAD to address all of them. A minimal version also exists for easier patching.

Remote DNS-over-QUIC (DoQ) flow-control assertion failure in libngtcp2

A remote unauthenticated client can trigger a libngtcp2 assertion (if compiled with assertions on) and terminate the entire Unbound process using a single DNS-over-QUIC (DoQ) connection and one normal DNS query. This is caused by an erroneous error value passed to libngtcp2.

When ngtcp2_conn_writev_stream() returns NGTCP2_ERR_STREAM_DATA_BLOCKED, Unbound continues to call ngtcp2_ccerr_set_application_error() with a -1 error value. The int literal -1 is implicitly converted to the function's uint64_t error_code parameter as 0xFFFFFFFFFFFFFFFF. The follow-on ngtcp2_conn_write_connection_close() serialises that value as a QUIC variable-length integer; because 2^64-1 exceeds the 62-bit varint ceiling, ngtcp2_put_uvarintlen() fails assert(n < 4611686018427387904ULL) and the whole resolver process aborts. A remote, unauthenticated DoQ client can trigger this deterministically with a single QUIC connection by advertising initial_max_stream_data_bidi_local = 1 in its transport parameters and sending one DoQ query without ever reading the stream.

Unbound 1.25.2 includes a fix to use the correct error code when calling libngtcp2 functions.

There are two patches available that address the issue:

• minimal patch,
• complete patch (accompanying code improvements/tests)

If you cannot upgrade you can apply EITHER of the above patches manually on the Unbound source directory with patch -p1 < patch_CVE-2026-55991.diff.

This is part of the 1.25.2 security release containing multiple fixes. The combined patch can be applied INSTEAD to address all of them. A minimal version also exists for easier patching.

Possible heap buffer overflow when validator canonicalizes RDATA that contains domain name

When the validator builds the canonical RDATA form for an RRSIG-covered PX/RP/MINFO/SOA RRset, it computes the address of the second embedded domain name as datstart + dname_valid(datstart, ...) and passes it straight to query_dname_tolower() without checking that a second name is actually present in the RDATA. The wire-format parser accepts multi-dname RRs whose RDATA ends after the first name, so an attacker who runs a DNSSEC-signed authoritative server can deliver a record with an absent second domain name (e.g. SOA record) and cause query_dname_tolower() to walk label-by-label through stale bytes in the per-worker env->scratch_buffer, past the end of that heap allocation if msg-buffer-size has been lowered from the default.

This leads to heap buffer overflow and on a release build the outcome relies heavily on the contents of the buffer tail and the adjacent heap chunk.

Unbound 1.25.2 includes a fix that rejects truncated multi-dname RDATA at ingest.

If you cannot upgrade you can apply the patch manually on the Unbound source directory with patch -p1 < patch_CVE-2026-56416.diff.

This is part of the 1.25.2 security release containing multiple fixes. The combined patch can be applied INSTEAD to address all of them. A minimal version also exists for easier patching.

Degradation of resolution service when 'discard-timeout' and 'serve-expired-client-timeout' are combined in unusual configuration

When Unbound is configured with serve-expired: yes and serve-expired-client-timeout > discard-timeout > 0 (contrary to the suggested values), the discard-timeout branch during the serve expired logic drops an aged client reply without performing the correct accounting for the number of reply addresses for the query. Other identical branches outside of serve expired perform the correct decrement. Since the counter is never decremented in such scenario, it can reach the maximum limit and new clients for duplicate in-flight queries are silently dropped resulting in degradation of resolution service.

A malicious actor can exploit the vulnerability by querying the resolver for a client-controlled slow-on-demand authoritative zone that can drive the counter past the threshold.

Shipped defaults for serve-expired-client-timeout: 1800 and discard-timeout: 1900 make the branch unreachable.

Unbound 1.25.2 includes a fix to properly account for the dropped replies.

If you cannot upgrade you can apply the patch manually on the Unbound source directory with patch -p1 < patch_CVE-2026-56444.diff.

This is part of the 1.25.2 security release containing multiple fixes. The combined patch can be applied INSTEAD to address all of them. A minimal version also exists for easier patching.

Degradation of resolution service from improperly accounted client-terminated DNS-over-QUIC queries

Client terminated DNS-over-QUIC (DoQ) queries are not accounted properly by Unbound resulting in low-cost inflation of the waiting number of replies for already in-flight resolution queries. This results in degradation of resolution service for new clients for already in-flight queries.

A malicious actor can exploit the vulnerability by issuing DoQ queries for query names that need resolution and proceeding on immediately terminating the query by one of STOP_SENDING/RESET_STREAM/CONNECTION_CLOSE QUIC frames. Those terminated DoQ queries are not properly counted for and keep inflating the number of waiting replies for in-flight queries. When the maximum is reached, it results in silent query drops for new clients needing resolution for already in-flight queries.

This vulnerability needs Unbound to be compiled with DoQ support (--with-libngtcp2) and the quic-port to be configured for the listening interfaces. Additionally, a malicious actor needs access to multiple source IPs to bypass the by-default configured wait-limit option.

Unbound 1.25.2 includes a fix to properly account the terminated DoQ queries.

There are two patches available that address the issue:

• minimal patch,
• complete patch (accompanying code improvements/tests)

If you cannot upgrade you can apply EITHER of the above patches manually on the Unbound source directory with patch -p1 < patch_CVE-2026-41637.diff.

This is part of the 1.25.2 security release containing multiple fixes. The combined patch can be applied INSTEAD to address all of them. A minimal version also exists for easier patching.

Extra fix for CVE-2026-40622 to also clamp the TTL of A/AAAA records disallowing a one-time 'ghost domain' delegation renewal via glue records

A similar vulnerability as with CVE-2026-40622 in the "ghost domain names" family of attacks was found in Unbound that could extend the ghost domain window by up to one cached TTL configured value for A/AAAA glue records.

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 A/AAAA query can cause Unbound to overwrite the cached expired parent-side glue 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 query is required since Unbound implicitly performs that query. This is a variant of CVE-2026-40622 which only addressed the NS query.

Unbound 1.25.2 includes a fix that does not allow extension of TTLs for (parent) A/AAAA records regardless of their trust.

There are two patches available that address the issue:

• minimal patch,
• complete patch (accompanying code improvements/tests)

If you cannot upgrade you can apply EITHER of the above patches manually on the Unbound source directory with patch -p1 < patch_CVE-2026-42955.diff.

This is part of the 1.25.2 security release containing multiple fixes. The combined patch can be applied INSTEAD to address all of them. A minimal version also exists for easier patching.

Off-by-one error in 'harden-below-nxdomain' logic can shadow a stub/forward zone by a legitimate parent's NXDOMAIN

Stub or forward zones where the name is below an intermediate labed below a DNSSEC signed zone could be shadowed by the intermediate label's secure NXDOMAIN answer from the parent. This is caused by an off-by-one error in harden-below-nxdomain logic; enabled by default. It effectively bypasses the configuration and the configured stub/forward zone is never contacted.

harden-below-nxdomain does an upward DNS cache walk together with a delegation point guard that does not allow NXDOMAIN synthesis above stub/forward zones.

The guard tests the domain name but before stripping a label. This results in an iteration where the domain name equals the configured stub/forward zone apex that passes the guard, strips one more label, and probes the cache at the apex's immediate public parent. If that parent has a cached DNSSEC-secure NXDOMAIN, which it will for any private namespace nested two or more labels under a signed public name, the walk returns it and the configured stub/forward upstream is never contacted.

This can only be triggered by the query for the intermediate label (between the stub/forward apex and the DNSSEC parent zone).

Unbound 1.25.2 includes the off-by-one fix.

If you cannot upgrade you can apply the patch manually on the Unbound source directory with patch -p1 < patch_CVE-2026-44687.diff.

This is part of the 1.25.2 security release containing multiple fixes. The combined patch can be applied INSTEAD to address all of them. A minimal version also exists for easier patching.

A wildcard replay, as another piece of data, triggers poisoning in the serve expired reply path

A replay of a wildcard rrset as another piece of data, could be briefly considered DNSSEC secure based only on the RRSIG validation and stored into cache, before later validation treats it as bogus based on NSEC validation. When the resolving thread puts secure on the rrset, and another thread that is on the serve expired path then picks up the updated rrset contents with the secure status for a reply, it can be used to change a specific record, next to a wildcard that could be covered by the wildcard, into the wildcard.

A malicious actor can exploit the possible poisonous effect by having any DNSSEC-singed domain (irrelevant to the victim domain) and a CNAME wrapper record that points to a record next to a wildcard (that could be covered by the wildcard). Then quering Unbound for the wildcard sibling record would seed the secure message. A later (after expiry) query for the CNAME wrapper would need to resolve the target sibling record. If the wildcard replay is injected into the response, the wildcard rrset will update the expired sibling record with a secure status before completing proper wildcard validation with NSEC records and eventually treating the CNAME wrapper answer as bogus. The updated poisoned rrset is now secure and points to the wildcard.

This vulnerability is explicit for the serve expired path and needs injection of the signed wildcard rrset without the NSEC accompanying rrset.

Unbound 1.25.2 includes fixes so that wildcards do not have their secure status put in cache, until this is proven as the RRSIG verify is not enough by itself. Then when the NSECs do not check out, it puts bogus on the rrset, so that a later message store by the validator does not put secure on the rrset. The rrset cache then always has correct name expansion and wildcard data, when it is labelled secure.

If you cannot upgrade you can apply the patch manually on the Unbound source directory with patch -p1 < patch_CVE-2026-46582.diff.

This is part of the 1.25.2 security release containing multiple fixes. The combined patch can be applied INSTEAD to address all of them. A minimal version also exists for easier patching.

DNS Cookie bypass when combined with proxy-protocol use

When Unbound listens on a proxy-protocol-port interface with answer-cookie: yes, the RFC 9018 server-cookie SipHash is computed over the proxy's wire address instead of the PROXYv2-declared client. One server cookie obtained through a given proxy node therefore validates for every PROXYv2-declared source behind that node. On a UDP+proxy-protocol front, an off-path attacker can harvest one cookie with a single legitimate query, then replay it under any spoofed source and pass DNS Cookie checks that were deployed to defeat this in the first place.

Unbound 1.25.2 includes a fix to always use the DNS client's IP for DNS server cookie hash calculations.

If you cannot upgrade you can apply the patch manually on the Unbound source directory with patch -p1 < patch_CVE-2026-54478.diff.

This is part of the 1.25.2 security release containing multiple fixes. The combined patch can be applied INSTEAD to address all of them. A minimal version also exists for easier patching.

Privacy/configuration issue when adding local data in views through 'unbound-control'

The view_local_data and view_local_datas commands of unbound-control create a bare local zones tree for an already configured named view when the view is configured with no local data to begin with. However, the creation through the control interface omits adding the default-protected zones (e.g., RFC 1918 reverse, AS112 zones, .onion, .localhost). Once the local zone tree exists without the defaults, every query for a default-protected name from a client mapped to that view escapes to the public DNS via the iterator instead of being answered locally, bypassing local policy expectations.

Unbound 1.25.2 includes a fix to make sure that the defaults are added when creating view local zones via unbound-control.

If you cannot upgrade you can apply the patch manually on the Unbound source directory with patch -p1 < patch_CVE-2026-55708.diff.

This is part of the 1.25.2 security release containing multiple fixes. The combined patch can be applied INSTEAD to address all of them. A minimal version also exists for easier patching.

Possible arbitrary code execution during DNSSEC validation

A vulnerability was found in Unbound's 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.

There are two patches available that address the issue:

• minimal patch,
• complete patch (accompanying code improvements/tests)

If you cannot upgrade you can apply EITHER of the above patches manually on the Unbound source directory with patch -p1 < patch_CVE-2026-33278.diff.

This is part of the 1.25.1 security release containing multiple fixes. The combined patch can be applied INSTEAD to address all of them. A minimal version also exists for easier patching.

Heap overflow with multiple NSID, COOKIE, PADDING EDNS options

A vulnerability was found in Unbound 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.

There are two patches available that address the issue:

• minimal patch,
• complete patch (accompanying code improvements/tests)

If you cannot upgrade you can apply EITHER of the above patches manually on the Unbound source directory with patch -p1 < patch_CVE-2026-42944.diff.

This is part of the 1.25.1 security release containing multiple fixes. The combined patch can be applied INSTEAD to address all of them. A minimal version also exists for easier patching.

Crash during DNSSEC validation of malicious content

A denial of service vulnerability was found in Unbound's 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.

If you cannot upgrade you can apply the patch manually on the Unbound source directory with patch -p1 < patch_CVE-2026-42959.diff.

This is part of the 1.25.1 security release containing multiple fixes. The combined patch can be applied INSTEAD to address all of them. A minimal version also exists for easier patching.

Packet of death with DNSCrypt

A denial of service vulnerability has been discovered in Unbound 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.

If you cannot upgrade you can apply the patch manually on the Unbound source directory with patch -p1 < patch_CVE-2026-32792.diff.

This is part of the 1.25.1 security release containing multiple fixes. The combined patch can be applied INSTEAD to address all of them. A minimal version also exists for easier patching.

Another "ghost domain names" attack variant

A vulnerability in the "ghost domain names" family of attacks was found in Unbound 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.

If you cannot upgrade you can apply the patch manually on the Unbound source directory with patch -p1 < patch_CVE-2026-40622.diff.

This is part of the 1.25.1 security release containing multiple fixes. The combined patch can be applied INSTEAD to address all of them. A minimal version also exists for easier patching.

Long list of incoming EDNS options degrades performance

A degradation of service attack has been discovered in Unbound 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).

If you cannot upgrade you can apply the patch manually on the Unbound source directory with patch -p1 < patch_CVE-2026-41292.diff.

This is part of the 1.25.1 security release containing multiple fixes. The combined patch can be applied INSTEAD to address all of them. A minimal version also exists for easier patching.

Jostle logic bypass degrades resolution performance

A vulnerability was found in Unbound's 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.

If you cannot upgrade you can apply the patch manually on the Unbound source directory with patch -p1 < patch_CVE-2026-42534.diff.

This is part of the 1.25.1 security release containing multiple fixes. The combined patch can be applied INSTEAD to address all of them. A minimal version also exists for easier patching.

Degradation of service with unbounded NSEC3 hash calculations

A vulnerability in Unbound's DNSSEC validator was found 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.

If you cannot upgrade you can apply the patch manually on the Unbound source directory with patch -p1 < patch_CVE-2026-42923.diff.

This is part of the 1.25.1 security release containing multiple fixes. The combined patch can be applied INSTEAD to address all of them. A minimal version also exists for easier patching.

Possible cache poisoning via promiscuous records for the authority section

(complement fix to CVE-2025-11411)

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.

If you cannot upgrade you can apply the patch manually on the Unbound source directory with patch -p1 < patch_CVE-2026-42960.diff.

This is part of the 1.25.1 security release containing multiple fixes. The combined patch can be applied INSTEAD to address all of them. A minimal version also exists for easier patching.

Unbounded name compression in certain cases causes degradation of service

(complement fix to CVE-2024-8508)

A vulnerability has been discovered in Unbound 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.

If you cannot upgrade you can apply the patch manually on the Unbound source directory with patch -p1 < patch_CVE-2026-44390.diff.

This is part of the 1.25.1 security release containing multiple fixes. The combined patch can be applied INSTEAD to address all of them. A minimal version also exists for easier patching.

Use after free and crash under special conditions in RPZ code

A locking inconsistency vulnerability was found in Unbound 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 cannot upgrade you can apply the patch manually on the Unbound source directory with patch -p1 < patch_CVE-2026-44608.diff.

This is part of the 1.25.1 security release containing multiple fixes. The combined patch can be applied INSTEAD to address all of them. A minimal version also exists for easier patching.

Possible domain hijacking via promiscuous records in the authority section

Several multi-vendor cache poisoning vulnerabilities have been discovered in caching resolvers for non-DNSSEC protected data.

Unbound is vulnerable for some of these cases that could lead to domain hijacking.

Promiscuous NS RRSets that complement positive DNS replies in the authority section can be used to trick resolvers to update their delegation information for the zone. Usually these RRSets are used to update the resolver's knowledge of the zone's name servers.

A malicious actor can exploit the possible poisonous effect by injecting NS RRSets (and possibly their respective address records) in a reply. This could be done for example by trying to spoof a packet or fragmentation attacks.

Unbound would then proceed to update the NS RRSet data it already has since the new data has enough trust for it, i.e., in-zone data for the delegation point.

Unbound 1.24.1 includes a fix that scrubs unsolicited NS RRSets (and their respective address records) from replies mitigating the possible poison effect.

Update: Unbound 1.24.2 includes an additional fix that scrubs unsolicited NS RRSets (and their respective address records) from YXDOMAIN and non-referral nodata replies as well, mitigating the possible poison effect.

Unbound 1.24.2 fully addresses the vulnerability.

If you cannot upgrade you can also apply the individual patches in order: the 1.24.1 patch (applies on 1.24.0) and the 1.24.2 patch (applies on 1.24.1) manually. To do this, apply the patches on the Unbound source directory with patch -p1 < patch_CVE-2025-11411_option_tests.diff, and/or patch -p1 < patch_CVE-2025-11411_2_wtests.diff and then run make install to install Unbound.

Cache poisoning via the ECS-enabled Rebirthday Attack

A multi-vendor cache poisoning vulnerability named "Rebirthday Attack" has been discovered in caching resolvers that support EDNS Client Subnet (ECS). Unbound is also vulnerable when compiled with ECS support, i.e., --enable-subnet, AND configured to send ECS information along with queries to upstream name servers, i.e., at least one of the send-client-subnet, client-subnet-zone or client-subnet-always-forward options is used.

Resolvers supporting ECS need to segregate outgoing queries to accommodate for different outgoing ECS information. This re-opens up resolvers to a birthday paradox attack (Rebirthday Attack) that tries to match the DNS transaction ID in order to cache non-ECS poisonous replies.

A malicious actor can then exploit the Rebirthday Attack in two steps. First, send queries to Unbound that would result in segregated ECS outbound traffic from Unbound for a single domain. Second, send non-ECS poisonous replies to Unbound trying to guess the DNS transaction ID before the real answer from the upstream name server arrives.

Unbound version 1.23.1 includes a fix that disregards replies that came back without ECS when ECS was expected. Instead it creates a non-ECS sub query, that could be aggregated with other such queries, to explicitly query for the non-ECS authoritative answer. The re-introduced query aggregation then defeats the Rebirthday Attack.

Unbound 1.23.1 contains a patch. If you cannot upgrade you can also apply the patch manually. To do this, apply the patch on the Unbound source directory with patch -p1 < patch_CVE-2025-5994_2.diff and then run make install to install Unbound.

Unbounded name compression could lead to Denial of Service

Malicious upstreams responses with very large RRsets 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.

The vulnerability can be exploited by a malicious actor 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.

Unbound version 1.21.1 introduces a hard limit on the number of name compression calculations it is willing to do per packet. Packets that need more compression will result in semi-compressed packets or truncated packets, even on TCP for huge messages, to avoid locking the CPU for long.

This change should not affect normal DNS traffic.

Unbound 1.21.1 contains a patch. If you cannot upgrade you can also apply the patch manually. To do this, apply the patch on the Unbound source directory with patch -p1 < patch_CVE-2024-8508.diff and then run make install to install Unbound.

Unbound vulnerable to the "DNSBomb" pulsing DoS amplification attack

The DNSBomb attack, via specially timed DNS queries and answers, can cause a Denial of Service on resolvers and spoofed targets.

Unbound itself is not vulnerable for DoS, rather it can be used to take part in a pulsing DoS amplification attack.

The DNSBomb attack works by sending low-rate spoofed queries for a malicious zone to Unbound. By controlling the delay of the malicious authoritative answers, Unbound slowly accumulates pending answers for the spoofed addresses. When the authoritative answers become available to Unbound at the same time, Unbound starts serving all the accumulated queries. This results into large-sized, concentrated response bursts to the spoofed addresses.

From version 1.20.0 on, Unbound introduces a couple of configuration options to help mitigate the impact. Their complete description can be found in the included manpages but they are also briefly listed here together with their current default values for convenience:

• discard-timeout: 1900

  After 1900 ms a reply to the client will be dropped. Unbound would still work on the query but refrain from replying in order to not accumulate a huge number of "old" replies. Legitimate clients retry on timeouts.

• wait-limit: 1000 / wait-limit-cookie: 10000

  Limits the amount of client queries that require recursion (cache-hits are not counted) per IP address. More recursive queries than the allowed limit are dropped. Clients with a valid EDNS Cookie can have a different limit, higher by default. wait-limit: 0 disables all wait limits.

• wait-limit-netblock / wait-limit-cookie-netblock

  These do not have a default value but they can fine grain configuration for specific netblocks. With or without EDNS Cookies.

The options above are trying to shrink the DNSBomb window so that the impact of the DoS from Unbound is significantly lower than it used to be and making the attack, and Unbound's participation, less tempting for attackers.

Unbound 1.20.0 contains a patch. If you cannot upgrade you can also apply the patch manually. To do this, apply the patch on the Unbound source directory with patch -p1 < patch_CVE-2024-33655.diff and then run make install to install Unbound.

Denial of service when trimming EDE text on positive replies

Unbound 1.18.0 introduced a feature that removes EDE records from responses with size higher than the client's advertised buffer size. Before removing all the EDE records however, it would try to see if trimming the extra text fields on those records would result in an acceptable size while still retaining the EDE codes. Due to an unchecked condition, the code that trims the text of the EDE records could loop indefinitely. This happens when Unbound would reply with attached EDE information on a positive reply and the client's buffer size is smaller than the needed space to include EDE records.

The vulnerability can only be triggered when the 'ede: yes' option is used; non default configuration.

From version 1.19.2 on, the code is fixed to avoid looping indefinitely.

Unbound 1.19.2 contains a patch. If you cannot upgrade you can also apply the patch manually. To do this, apply the patch on the Unbound source directory with patch -p1 < patch_CVE-2024-1931.diff and then run make install to install Unbound.

DNSSEC verification complexity can be exploited to exhaust CPU resources and stall DNS resolvers

A DNSSEC validation vulnerability has been discovered in various DNSSEC validating software. The vulnerability has an assigned number of CVE-2023-50387 and is referred here as the KeyTrap vulnerability.

The KeyTrap vulnerability works by using a combination of Keys (also colliding Keys), Signatures and number of RRSETs on a malicious zone. Answers from that zone can force a DNSSEC validator down a very CPU intensive and time costly validation path.

It can force Unbound to spend an enormous time (comparative to regular traffic) validating a single specially crafted DNSSEC response while everything else is on hold for that thread. A trivially orchestrated attack could render all threads busy with such responses leading to denial of service.

From version 1.19.1 on, Unbound introduces suspension on DNSSEC response validations that seem to require more attempts than Unbound is willing to make per response validation run. Suspension means that Unbound will continue with other work before resuming a suspended validation offering CPU time between validation resumptions to other tasks. There is a backoff timer when suspending which is further influenced by the number of suspends already used and the amount of work currently in Unbound.

The introduced builtin limits in Unbound are:

• Max 4 DNSSEC key collissions are allowed when building chain of trust. More than that without a secure key treats the delegation as bogus.
• 8 validation attempts per RRSET (combination of keys + signatures). If more are needed and Unbound has yet to find a valid signature the RRSET is treated as bogus.
• More than 8 validation attempts per answer will suspend validation.
• The limit of total suspensions is 16 after which the query will error out. Any completed RRSET validations populate the cache for use in future queries.

While under attack Unbound could show higher CPU load because of the needed validations but the suspend strategy would guarantee the CPU is not locked on any particular validation task.

Unbound 1.19.1 contains a patch. If you cannot upgrade you can also apply the patch manually. To do this, apply the patch on the Unbound source directory with patch -p1 < patch_CVE-2023-50387_CVE-2023-50868.diff and then run make install to install Unbound.

This is a shared patch with CVE-2023-50868 below

NSEC3 closest encloser proof can exhaust CPU

A DNSSEC validation vulnerability has been discovered in various DNSSEC validating software. The vulnerability has an assigned number of CVE-2023-50868 and is referred here as the NSEC3 vulnerability.

The NSEC3 vulnerability uses specially crafted responses on a malicious zone with multiple NSEC3 RRSETs to force a DNSSEC validator down a very CPU intensive and time costly NSEC3 hash calculation path.

It can force Unbound to spend an enormous time (comparative to regular traffic) validating a single specially crafted DNSSEC response while everything else is on hold for that thread. A trivially orchestrated attack could render all threads busy with such responses leading to denial of service.

From version 1.19.1 on, Unbound introduces suspension on DNSSEC response validations that seem to require more attempts than Unbound is willing to make per response validation run. Suspension means that Unbound will continue with other work before resuming a suspended validation offering CPU time between validation resumptions to other tasks. There is a backoff timer when suspending which is further influenced by the number of suspends already used and the amount of work currently in Unbound.

The introduced builtin limits for the NSEC3 vulnerability in Unbound are:

• 8 NSEC3 hash calculations are allowed before suspension. More than that will suspend validation.
• The limit of total suspensions is 16 after which the query will error out. Any completed RRSET validations populate the cache for use in future queries.

While under attack Unbound could show higher CPU load because of the needed validations but the suspend strategy would guarantee the CPU is not locked on any particular validation task.

Unbound 1.19.1 contains a patch. If you cannot upgrade you can also apply the patch manually. To do this, apply the patch on the Unbound source directory with patch -p1 < patch_CVE-2023-50387_CVE-2023-50868.diff and then run make install to install Unbound.

This is a shared patch with CVE-2023-50387 above

Non-Responsive Delegation Attack

A vulnerability named 'Non-Responsive Delegation Attack' (NRDelegation Attack) has been discovered in various DNS resolving software. The NRDelegation Attack works by having a malicious delegation with a considerable number of non responsive nameservers. The attack starts by querying a resolver for a record that relies on those unresponsive nameservers.

The attack can cause a resolver to spend a lot of time/resources resolving records under a malicious delegation point where a considerable number of unresponsive NS records reside. It can trigger high CPU usage in some resolver implementations that continually look in the cache for resolved NS records in that delegation. This can lead to degraded performance and eventually denial of service in orchestrated attacks.

Unbound does not suffer from high CPU usage, but resources are still needed for resolving the malicious delegation. Unbound will keep trying to resolve the record until hard limits are reached. Based on the nature of the attack and the replies, different limits could be reached.

From version 1.16.3 on, Unbound introduces fixes for better performance when under load, by cutting opportunistic queries for nameserver discovery and DNSKEY prefetching and limiting the number of times a delegation point can issue a cache lookup for missing records.

Unbound 1.16.3 contains a patch. If you cannot upgrade you can also apply the patch manually. To do this, apply the patch on the Unbound source directory with patch -p1 < patch_CVE-2022-3204.diff and then run make install to install Unbound.

Novel "ghost domain names" attack by updating almost expired delegation information

NLnet Labs Unbound, up to and including version 1.16.1, is vulnerable to a novel type of the "ghost domain names" attack. The vulnerability works by targeting an Unbound instance. Unbound is queried for a rogue domain name when the cached delegation information is about to expire. The rogue nameserver delays the response so that the cached delegation information is expired. Upon receiving the delayed answer containing the delegation information, Unbound overwrites the now expired entries. This action can be repeated when the delegation information is about to expire making the rogue delegation information ever-updating. From version 1.16.2 on, Unbound stores the start time for a query and uses that to decide if the cached delegation information can be overwritten.

Unbound 1.16.2 contains a patch. If you cannot upgrade you can also apply the patch manually. To do this, apply the patch on the Unbound source directory with patch -p1 < patch_CVE-2022-30698_CVE-2022-30699.diff and then run make install to install Unbound.

This is a shared patch with CVE-2022-30698 below

Novel "ghost domain names" attack by introducing subdomain delegations

NLnet Labs Unbound, up to and including version 1.16.1 is vulnerable to a novel type of the "ghost domain names" attack. The vulnerability works by targeting an Unbound instance. Unbound is queried for a subdomain of a rogue domain name. The rogue nameserver returns delegation information for the subdomain that updates Unbound's delegation cache. This action can be repeated before expiry of the delegation information by querying Unbound for a second level subdomain which the rogue nameserver provides new delegation information. Since Unbound is a child-centric resolver, the ever-updating child delegation information can keep a rogue domain name resolvable long after revocation. From version 1.16.2 on, Unbound checks the validity of parent delegation records before using cached delegation information.

Unbound 1.16.2 contains a patch. If you cannot upgrade you can also apply the patch manually. To do this, apply the patch on the Unbound source directory with patch -p1 < patch_CVE-2022-30698_CVE-2022-30699.diff and then run make install to install Unbound.

This is a shared patch with CVE-2022-30699 above

Local symlink attack

Unbound when writing and later chown'ing the PID file would not check if an existing file was a symlink. This is a local vulnerability that could create a Denial of Service of the system Unbound is running on. It requires an attacker having access to the limited permission user Unbound runs as and point through the symlink to a critical file on the system.

Unbound 1.13.0 contains a patch. If you cannot upgrade you can also apply the patch manually. To do this, apply the patch on the Unbound source directory with patch -p1 < patch_cve-2020-28935_unbound.diff and then run make install to install Unbound.

Vulnerability in Domain Parse

Fuzzing of the Unbound code made us aware of issues in the parser of received answers. Malformed answers received from upstream servers can result in Unbound entering an infinite loop and thereby becoming unresponsive. When compiled with --enable-debug it is also possible to trigger an assertion, resulting in Unbound to crash.

Unbound 1.10.1 contains a patch. If you cannot upgrade you can also apply the patch manually. To do this, apply the patch on Unbound source directory with patch -p1 < filename, then run make install to install Unbound.

NXNSAttack

Researchers from Tel Aviv University discovered an issue in Unbound and other DNS resolvers that makes it possible to have a single incoming query result in a large number of outgoing queries. This amplification makes it possible for Unbound to be used in a denial of service attack. The researchers discovering this called this attack the NXNSattack.

This attack makes use of cache bypassing using random subdomains in the NSDNAME in NS records. When these delegation records are received during iteration, and the answer does not contain glue records, a resolver has to send out a query to the get the IP address for one of the names. When this query fails (for example because the random name does not exist) a resolver will try the next one. A large set of NS records with random names can result in a large number of outgoing queries going to the same target. More details about this attack will be available in the research paper.

Unbound 1.10.1 contains a patch. If you cannot upgrade you can also apply the patch manually. To do this, apply the patch on Unbound source directory with patch -p1 < filename, then run make install to install Unbound.

Vulnerability in IPSEC module

Due to unsanitized characters passed to the ipsecmod-hook shell command, it is possible for Unbound to allow shell code execution from a specially crafted IPSECKEY answer.

This issue can only be triggered when all of the below conditions are met:

• unbound was compiled with --enable-ipsecmod support, and
• ipsecmod is enabled and used in the configuration (either in the configuration file or using unbound-control), and
• a domain is part of the ipsecmod-whitelist (if ipsecmod-whitelist is used), and
• unbound receives an A/AAAA query for a domain that has an A/AAAA record(s) and an IPSECKEY record(s) available.

The shell code execution can then happen if either the qname or the gateway field of the IPSECKEY (when gateway type == 3) contain a specially crafted domain name.

Unbound 1.9.5 contains a patch. If you cannot upgrade you can also apply the patch manually. To do this, apply the patch on Unbound source directory with patch -p1 < filename, then run make install to install Unbound.

Vulnerability in parsing NOTIFY queries

Due to an error in parsing NOTIFY queries, it is possible for Unbound to continue processing malformed queries and may ultimately result in a pointer dereference in uninitialized memory. This results in a crash of the Unbound daemon.

Unbound 1.9.4 contains a patch. If you cannot upgrade you can also apply the patch manually. To do this, apply the patch on Unbound source directory with patch -p0 < filename, then run make install to install Unbound.

Vulnerability in the processing of wildcard synthesized NSEC records

We discovered a vulnerability in the processing of wildcard synthesized NSEC records. While synthesis of NSEC records is allowed by RFC4592, these synthesized owner names should not be used in the NSEC processing. This does, however, happen in Unbound 1.6.7 and earlier versions.

Unbound 1.6.8 contains a patch. If you cannot upgrade you can also apply the patch manually. To do this, apply the patch on Unbound source directory with patch -p0 < filename, then run make install to install Unbound.

A special thanks goes out to Karst Koymans (University of Amsterdam) for sparking the discovery of this vulnerability by Ralph Dolmans (NLnet Labs).

Ghost domain names attack

The resolver in Unbound before 1.4.11 overwrites cached server names and TTL values in NS records during the processing of a response to an A record query, which allows remote attackers to trigger continued resolvability of revoked domain names via a "ghost domain names" attack. To resolve this issue, upgrade to a newer version of Unbound.

Incorrect proof processing for NSEC3-signed zone

validator/val_nsec3.c in Unbound before 1.4.13p2 does not properly perform proof processing for NSEC3-signed zones, which allows remote DNS servers to cause a denial of service (daemon crash) via a malformed response that lacks expected NSEC3 records, a different vulnerability than CVE-2011-4528.

Unbound 1.4.14 contains a patch, but 1.4.14rc1 is vulnerable. If you cannot upgrade you can also apply a patch. For unbound version 1.4.0 - 1.4.13, apply this patch and for version 1.0.1 - 1.3.4 use this patch. To do this, apply the patch on Unbound source directory with patch -p0 < filename, then run make install to install Unbound.

Processing of duplicate CNAME records in a signed zone

Unbound crashes when confronted with a non-standard response from a server for a domain. This domain produces duplicate RRs from a certain type and is DNSSEC signed. Unbound also crashes when confronted with a query that eventually, and under specific circumstances, resolves to a domain that misses expected NSEC3 records.

Unbound 1.4.14 contains a patch, but 1.4.14rc1 is vulnerable. If you cannot upgrade you can also apply a patch. For unbound version 1.4.0 - 1.4.13, apply this patch and for version 1.0.1 - 1.3.4 use this patch. To do this, apply the patch on Unbound source directory with patch -p0 < filename, then run make install to install Unbound.