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

In NLnet Labs Unbound up to and including version 1.25.1, 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 + dnamevalid(datstart, ...)' and passes it straight to 'querydnametolower()' 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 'querydnametolower()' to walk label-by-label through stale bytes in the per-worker 'env->scratchbuffer', 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.

In NLnet Labs Unbound 1.22.0 up to and including 1.25.1, 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 'ngtcp2connwritevstream()' returns 'NGTCP2ERRSTREAMDATABLOCKED', Unbound continues to call 'ngtcp2ccerrsetapplicationerror()' with a '-1' error value. The 'int' literal '-1' is implicitly converted to the function's 'uint64t errorcode' parameter as '0xFFFFFFFFFFFFFFFF'. The follow-on 'ngtcp2connwriteconnectionclose()' serialises that value as a QUIC variable-length integer; because '2^64-1' exceeds the 62-bit varint ceiling, 'ngtcp2putuvarintlen()' 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 'initialmaxstreamdatabidilocal = 1' in its transport parameters and sending one DoQ query without ever reading the stream.

In NLnet Labs Unbound 1.7.0 up to and including 1.25.1, 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').

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

In NLnet Labs Unbound 1.6.0 up to and including 1.25.1, the 'viewlocaldata' and 'viewlocaldatas' 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.

DNS Cookie bypass when combined with proxy-protocol use

In NLnet Labs Unbound 1.25.0 up to and including 1.25.1, a fix 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.

In NLnet Labs Unbound 1.4.22 up to and including 1.25.1, 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 SOREUSEPORT 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 SOREUSEPORT 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.

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

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

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

In NLnet Labs Unbound 1.15.0 up to and including 1.25.1, the TLS server name used for DNS-over-TLS (DoT) forwarded queries is tied to a struct's ('servicedquery') lifetime but also referenced by another struct ('waitingtcp'). 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.

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

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

In NLnet Labs Unbound 1.13.2 up to and including 1.25.1, 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).

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

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

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

In Unbound 1.9.0 up to and including 1.25.1, 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.

In NLnet Labs Unbound 1.22.0 up to and including 1.25.1, when downstream DNS-over-QUIC (DoQ) is enabled, the first two bidirectional streams on a new QUIC connection (streamid 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.

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

'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 length 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 'findclosestoftype()', 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 'dnamequeryhash()' 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 length one.

Cross-zone wildcard cache poisoning via RRSIG.labels manipulation

Mercusys AC12G (EU) V1 with firmware AC12G(EU)V1200909 responds to version.bind CHAOS TXT queries, disclosing the DNS resolver software version (unbound 1.22.0), aiding targeted attacks against known vulnerabilities.

On 5/22/26 00:31, ROI AI wrote: I understand the costs, but simply hanging all the dirty laundry out is counter productive.   Working a change in public without going into sensitive details is reasonable, but pushing vuln reports to public is careless.

[...]

As a further data point backing up this theory: We’re seeing duplicate reports of the same issue found by multiple independent groups that use LLMs, within the embargo period.

-- Jacob From: Jacob Bachmeyer <jcb62281 () gmail com> To: <oss-security () lists openwall com> Date: Thu, 21 May 2026 21:02:51 -0700 Subject: Re: [oss-security] Coordinated Disclosure in the LLM Age

On 5/21/26 01:51, ROI AI wrote: Also the entire nonsense about making the found issues public - this is absurd and just exacerbates the asymmetry problem.

By keeping the reports private, the OSS teams can deal with the issues more on their timeline.

By making them public, they add timeline pressure and enable attackers.

Why are you making it harder on yourself?  It is the opposite of what you want to do. security issues private rather seriously---and that itself has costs. any benefit when the issue was found using a tool to search for issues, due to the risk of someone else using the same tool and finding the same issue.  If that other person is another whitehat, you get a duplicate report.  If that other person is a blackhat, you get an in-the-wild exploit while you were carefully maintaining an embargo. [...]

From: ROI AI < mailto:sales () roiai ca > To: "oss-security"< mailto:oss-security () lists openwall com > Date: Wed, 20 May 2026 22:26:21 -0700 Subject: Re: [oss-security] Coordinated Disclosure in the LLM Age

People are shooting the messengers here.   The fact is - we are going through a generational security event due to the advancement of LLMs. amount of "AI" slop that has buried maintainers of major packages.  Have you forgotten already that curl had to cancel their bug bounty due to excessive "AI" slop submissions? It is also both trivial and extremely effective to use Agentic analysis to filter security reports. be incapable of precise analysis.  I understand talking your own book, but there are serious externalities here and I cannot let this go unanswered. genuine issue?  Now the issue does not get fixed... "AI" hallucinations?  Remember that the same hallucination-prone model might be doing the analysis as made the bogus report.  How, exactly, is a model supposed to recognize its own hallucinations? As for 'duplicates', people are claiming this when I have seen little evidence.  I reported a dozen or so to one major project and no one has yet claimed invalid or duplicate. manages inserting them into a bug tracker.  I am inclined to trust their experience over your hand-waving dismissal. in many projects, sent straight to the bit bucket, especially if found to be invalid.  You should not expect a response informing you that your report is invalid, as most maintainers have likely stopped bothering to send those. Moreover, if 'duplicates' are found, then that is a good signal for prioritization. issue may be "low-hanging fruit" and therefore already quasi-public.  In other words, duplicate reports could be a signal to dump the embargo and move faster to fix the issue.  (Remember that working under embargo has costs?  Those costs can extend the time to patch.) Let's stop talking about how the vulns are found and start fixing them with urgency. (< mailto:sales () roiai ca >) and realize that I am probably debating a slop machine tasked with promoting a product.  I will send this anyway, for the benefit of my fellow humans who will read this discussion and who might---just might---recognize your marketing efforts as the slop they are. ROI AI -- Jacob From: Alan Coopersmith < mailto: mailto:alan.coopersmith () oracle com > To: < mailto: mailto:oss-security () lists openwall com > Date: Wed, 20 May 2026 10:52:37 -0700 Subject: Re: [oss-security] Coordinated Disclosure in the LLM Age

On 4/28/26 07:58, Jeremy Stanley wrote: I'm sorely tempted, both due to the increased volume and the risk of premature disclosure, to just assume that any vulnerability reported as a result of research using an LLM is trivially discoverable by others, and give up trying to pretend there's any point to working it under embargo. Other maintainers under similar floods seem to agree:

Linux kernel: - https://lkml.org/lkml/2026/5/17/896 - https://docs.kernel.org/process/security-bugs.html

DNS servers (BIND, Unbound, PowerDNS): - https://indico.dns-oarc.net/event/56/contributions/1233/ - https://indico.dns-oarc.net/event/56/contributions/1233/attachments/1180/2539/presentation.pdf Confidential communication. No warranties or commitments unless in a signed agreement. If received in error, notify sender and delete. Unauthorized use prohibited.

Also the entire nonsense about making the found issues public - this is absurd and just exacerbates the asymmetry problem.

By keeping the reports private, the OSS teams can deal with the issues more on their timeline.

By making them public, they add timeline pressure and enable attackers.

Why are you making it harder on yourself?  It is the opposite of what you want to do.

If it's giving CVE credit to people who've taken the time and tokens to report these issues that concerns you, than just bundle the issues in one CVE.

ROI AI

From: ROI AI <sales () roiai ca> To: "oss-security"<oss-security () lists openwall com> Date: Wed, 20 May 2026 22:26:21 -0700 Subject: Re: [oss-security] Coordinated Disclosure in the LLM Age

People are shooting the messengers here.   The fact is - we are going through a generational security event due to the advancement of LLMs.

It is also both trivial and extremely effective to use Agentic analysis to filter security reports.

As for 'duplicates', people are claiming this when I have seen little evidence.  I reported a dozen or so to one major project and no one has yet claimed invalid or duplicate.

Moreover, if 'duplicates' are found, then that is a good signal for prioritization.

Let's stop talking about how the vulns are found and start fixing them with urgency.

ROI AI

From: Alan Coopersmith < mailto:alan.coopersmith () oracle com > To: < mailto:oss-security () lists openwall com > Date: Wed, 20 May 2026 10:52:37 -0700 Subject: Re: [oss-security] Coordinated Disclosure in the LLM Age

On 4/28/26 07:58, Jeremy Stanley wrote: I'm sorely tempted, both due to the increased volume and the risk of premature disclosure, to just assume that any vulnerability reported as a result of research using an LLM is trivially discoverable by others, and give up trying to pretend there's any point to working it under embargo. Other maintainers under similar floods seem to agree: Linux kernel: - https://lkml.org/lkml/2026/5/17/896 - https://docs.kernel.org/process/security-bugs.html DNS servers (BIND, Unbound, PowerDNS): - https://indico.dns-oarc.net/event/56/contributions/1233/ - https://indico.dns-oarc.net/event/56/contributions/1233/attachments/1180/2539/presentation.pdf -- -Alan Coopersmith- mailto:alan.coopersmith () oracle com Oracle Solaris Engineering - https://blogs.oracle.com/solaris Confidential communication. No warranties or commitments unless in a signed agreement. If received in error, notify sender and delete. Unauthorized use prohibited.

On 4/28/26 07:58, Jeremy Stanley wrote: Other maintainers under similar floods seem to agree:

Linux kernel: - https://lkml.org/lkml/2026/5/17/896 - https://docs.kernel.org/process/security-bugs.html

DNS servers (BIND, Unbound, PowerDNS): - https://indico.dns-oarc.net/event/56/contributions/1233/ - https://indico.dns-oarc.net/event/56/contributions/1233/attachments/1180/2539/presentation.pdf

-- -Alan Coopersmith- alan.coopersmith () oracle com Oracle Solaris Engineering - https://blogs.oracle.com/solaris

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).