A validly signed NSEC3 from an unrelated sibling zone may be accepted as an insecurity proof, downgrading a secure delegation and letting a forged unsigned answer through. This issue affects BIND 9 versions 9.11.0 through 9.18.50, 9.20.0 through 9.20.27, 9.21.0 through 9.21.25, 9.11.3-S1 through 9.18.50-S1, and 9.20.9-S1 through 9.20.27-S1.

In a query response, an attacker may send named multiple copies of a record that should only exist once (such as an SOA record). If the RDATA is the same on all the copies, the record is appended to the in-memory RDATA set, which can cause increased memory usage of the negative cache and possibly lead to other memory attack vectors. This issue affects BIND 9 versions 9.11.0 through 9.18.50, 9.20.0 through 9.20.27, 9.21.0 through 9.21.25, 9.11.3-S1 through 9.18.50-S1, and 9.20.9-S1 through 9.20.27-S1.

A BIND recursive resolver may experience excessive resource consumption if it encounters large numbers of a particular kind of invalid DNSSEC record. Default limits on "max-records-per-type" and "max-types-per-name" help mitigate the exposure. This issue affects BIND 9 versions 9.11.0 through 9.18.50, 9.20.0 through 9.20.27, 9.21.0 through 9.21.25, 9.11.3-S1 through 9.18.50-S1, and 9.20.9-S1 through 9.20.27-S1.

For a secondary zone with transfers restricted by TSIG, named may start to serve the data provided in a zone transfer before the final message with the TSIG signature arrives. This could allow an attacker that does not actually possess a valid TSIG signature to send unauthorized zone contents to a secondary server. Although no TSIG signature ever arrives, named does not rollback to the pre-transfer state. To exploit the vulnerability, the transfer must be a multi-message TCP IXFR, as described by RFC 8945. This issue affects BIND 9 versions 9.11.0 through 9.18.50, 9.20.0 through 9.20.27, 9.21.0 through 9.21.25, 9.11.3-S1 through 9.18.50-S1, and 9.20.9-S1 through 9.20.27-S1.

If a BIND resolver sends a query for a DNSSEC-signed authoritative zone, and the authoritative server replies with a valid wildcard answer and signed NSEC3 proof, followed by an unsigned NSEC at the same owner name, it will trigger an unexpected program exit. This issue affects BIND 9 versions 9.11.0 through 9.18.50, 9.20.0 through 9.20.27, 9.21.0 through 9.21.25, 9.11.3-S1 through 9.18.50-S1, and 9.20.9-S1 through 9.20.27-S1.

If BIND is loaded with a "named.conf" file that contains no global "options" block, an attacker can send a query of QTYPE TKEY which may cause an assertion failure and subsequent unexpected program exit. This issue affects BIND 9 versions 9.20.0 through 9.20.27, 9.21.0 through 9.21.25, and 9.20.9-S1 through 9.20.27-S1.

On a resolver configured to use dns64, if an applicable answer from the authoritative server is malformed in a specific way, the resolver named process will exit unexpectedly. This issue affects BIND 9 versions 9.11.0 through 9.18.50, 9.20.0 through 9.20.27, 9.21.0 through 9.21.25, 9.11.3-S1 through 9.18.50-S1, and 9.20.9-S1 through 9.20.27-S1.

A BIND resolver encountering an SVCB/HTTPS AliasMode record referencing 14 or more SVCB/HTTPS ServiceMode records may fail to properly deallocate internal resources. If this happens repeatedly, resource exhaustion will eventually prevent the resolver from performing new recursive lookups. This issue affects BIND 9 versions 9.18.0 through 9.18.50, 9.20.0 through 9.20.27, 9.21.0 through 9.21.25, 9.18.11-S1 through 9.18.50-S1, and 9.20.9-S1 through 9.20.27-S1.

A malformed zone may contain an NS or DNAME node above its origin, which named treats as a zone cut. If an attacker inserts a malformed zone into a BIND authoritative server (e.g., via zone transfer), queries for names inside the configured zone then lose authoritative status and return an out-of-zone delegation. On a server that also provides recursion BIND can follow this locally sourced cut and cache attacker-supplied data, affecting names outside the configured zone. This situation persists as long as the malformed zone remains in the zone database. This issue affects BIND 9 versions 9.11.0 through 9.18.50, 9.20.0 through 9.20.27, 9.21.0 through 9.21.25, 9.11.3-S1 through 9.18.50-S1, and 9.20.9-S1 through 9.20.27-S1.

An attacker can cause named to abort by sending a crafted DNS-over-HTTPS request with a cryptographically invalid SIG(0) record, and then closing the transport connection prematurely. This issue affects BIND 9 versions 9.20.0 through 9.20.27, 9.21.0 through 9.21.25, and 9.20.9-S1 through 9.20.27-S1.

An inapplicable NSEC record may be accepted by a named resolver as proof that no wildcard exists, which could allow an attacker at the same or an upstream level of the zone name to mask the existence of a victim's wildcard record. This issue affects BIND 9 versions 9.11.0 through 9.18.50, 9.20.0 through 9.20.27, 9.21.0 through 9.21.25, 9.11.3-S1 through 9.18.50-S1, and 9.20.9-S1 through 9.20.27-S1.

An attacker may be able to cause a named resolver to abort. The attack requires inducing the victim resolver to send multiple queries for a DNSSEC-signed zone hosted by an authoritative server under the control of the attacker. If the auth responds with a particular sequence of crafted answers, and those answers arrive in a particular order with particular timing, the named resolver will encounter a use-after-free bug, and abort. This issue affects BIND 9 versions 9.11.0 through 9.18.50, 9.20.0 through 9.20.27, 9.11.3-S1 through 9.18.50-S1, and 9.20.9-S1 through 9.20.27-S1.

If an attacker-controlled authoritative server can produce a negative answer that is exactly 65536 bytes, then a flaw in named results in a negative cache entry of 0 bytes. When this entry is subsequently read, named aborts. This issue affects BIND 9 versions 9.11.0 through 9.18.50, 9.20.0 through 9.20.27, 9.21.0 through 9.21.25, 9.11.3-S1 through 9.18.50-S1, and 9.20.9-S1 through 9.20.27-S1.

If a BIND resolver has cached a tree of SVCB/HTTPS AliasMode records, and is then queried for the root of that tree, the resolver will spend disproportionate CPU time constructing the response. This issue affects BIND 9 versions 9.18.0 through 9.18.50, 9.20.0 through 9.20.27, 9.21.0 through 9.21.25, 9.18.11-S1 through 9.18.50-S1, and 9.20.9-S1 through 9.20.27-S1.

On 16 September 2026, Internet Systems Consortium disclosed fourteen vulnerabilities affecting our BIND 9 software:

- CVE-2026-19033: Unauthenticated IXFR deltas are applied to the live zone before TSIG verification https://kb.isc.org/docs/cve-2026-19033 - CVE-2026-19662: qpcache NOQNAME proof use-after-free crashes recursive resolver https://kb.isc.org/docs/cve-2026-19662 - CVE-2026-19666: Use-after-free in queryaddnoqnameproof() via the DNS64 filter64 path https://kb.isc.org/docs/cve-2026-19666 - CVE-2026-19667: Remote assertion failure via 16-bit length truncation in dnsncacheadd() https://kb.isc.org/docs/cve-2026-19667 - CVE-2026-19668: Resource Exhaustion via Excessive DNSSEC Cryptographic Material Matching https://kb.isc.org/docs/cve-2026-19668 - CVE-2026-19941: checkwildcard() accepts an out-of-zone NSEC as a wildcard-nonexistence proof https://kb.isc.org/docs/cve-2026-19941 - CVE-2026-75029: Message parser retains every identical singleton RDATA, enabling wire-to-work amplification https://kb.isc.org/docs/cve-2026-75029 - CVE-2026-76163: named aborts on a TKEY query when the user configuration has no global options statement https://kb.isc.org/docs/cve-2026-76163 - CVE-2026-77119: NSEC3 insecure-referral proof can use unrelated cached NSEC3 RRsets https://kb.isc.org/docs/cve-2026-77119 - CVE-2026-77692: Unauthenticated remote crash of named via a single DoH SIG(0) request https://kb.isc.org/docs/cve-2026-77692 - CVE-2026-78301: Out-of-zone database nodes can become authoritative zone cuts https://kb.isc.org/docs/cve-2026-78301 - CVE-2026-80274: Validating resolver can abort while caching a mismatched NOQNAME proof https://kb.isc.org/docs/cve-2026-80274 - CVE-2026-81563: SVCB AliasMode additional-data error leaks qpcache references https://kb.isc.org/docs/cve-2026-81563 - CVE-2026-81736: Remote CPU denial of service through cached SVCB/HTTPS AliasMode trees https://kb.isc.org/docs/cve-2026-81736

New versions of BIND 9 are available:

- https://downloads.isc.org/isc/bind9/9.20.29/ - https://downloads.isc.org/isc/bind9/9.21.26/

For more information and other release formats, consult the ISC software download page: https://www.isc.org/download/

With the public announcement of these vulnerabilities, the embargo period is ended and any updated software packages that have been prepared may be released.

-- Nicki Křížek

Last updated 19 August 2026

Last updated 19 August 2026

If BIND encounters a particular invalid data structure in a DNS record, it will accept the invalid data, and may subsequently abort and exit.

On 22 July 2026, Internet Systems Consortium disclosed nine vulnerabilities affecting our BIND 9 software:

- CVE-2026-10723: Incorrect acceptance of NSEC3 records https://kb.isc.org/docs/cve-2026-10723 - CVE-2026-10822: Key Record using PRIVATEDNS algorithm may lead to unexpected exit https://kb.isc.org/docs/cve-2026-10822 - CVE-2026-11331: Potential wildcard CNAME RPZ policy bypass https://kb.isc.org/docs/cve-2026-11331 - CVE-2026-11605: Unnecessary validation of DNSSEC signed records https://kb.isc.org/docs/cve-2026-11605 - CVE-2026-11622: Potential memory usage beyond configured limits https://kb.isc.org/docs/cve-2026-11622 - CVE-2026-11721: Cache poisoning possible with label count discrepancy, RRSIG, and wildcards https://kb.isc.org/docs/cve-2026-11721 - CVE-2026-12617: Record ordering based unexpected exit with CNAME or DNAME https://kb.isc.org/docs/cve-2026-12617 - CVE-2026-13204: Unexpected exit in certain situations with NSEC and NSEC3 both present https://kb.isc.org/docs/cve-2026-13204 - CVE-2026-13321: DNSSEC Validation Bypass via Out-of-Zone NSEC Next Field https://kb.isc.org/docs/cve-2026-13321

New versions of BIND 9 are available:

- https://downloads.isc.org/isc/bind9/9.20.26/ - https://downloads.isc.org/isc/bind9/9.21.24/

For more information and other release formats, consult the ISC software download page: https://www.isc.org/download/

With the public announcement of these vulnerabilities, the embargo period is ended and any updated software packages that have been prepared may be released.

-- Best regards, Michał Kępień

BIND may accept incorrect child-zone NSEC3 records as valid, allowing forged authenticated NXDOMAIN responses for sibling zones. AC:H (high complexity) keeps severity at Medium despite S:C.

BIND may accept incorrect child-zone NSEC3 records as valid, allowing forged authenticated NXDOMAIN responses for sibling zones. AC:H (high complexity) keeps severity at Medium despite S:C.

If a provably insecure domain is covered by both an NSEC and NSEC3 record at the parent, and there exist an RRSIG for only one of these types, then BIND may exit unexpectedly with an assertion while validating this proof. This issue affects BIND 9 versions 9.11.0 through 9.18.50, 9.20.0 through 9.20.24, 9.21.0 through 9.21.23, 9.11.3-S1 through 9.18.50-S1, and 9.20.9-S1 through 9.20.24-S1.

If a provably insecure domain is covered by both NSEC and NSEC3 at the parent, with an RRSIG for only one type, BIND exits with an assertion during validation.

An attacker's zone can respond with an RRSIG with fewer labels than the zone it's in, causing named to produce a wildcard name shorter than the attacker's zone — resulting in cache poisoning. Requires synth-from-dnssec yes (which IS the default).

A DNSSEC validating resolver that is under a random subdomain attack against a DNSSEC-signed zone can suffer from runaway memory usage. The attacker needs to be able to send queries faster than the resolver can perform validation. The increased memory usage can be orders of magnitude beyond the limit configured in the max-cache-size parameter. This issue affects BIND 9 versions 9.11.0 through 9.18.50, 9.20.0 through 9.20.24, 9.21.0 through 9.21.23, 9.11.3-S1 through 9.18.50-S1, and 9.20.9-S1 through 9.20.24-S1.

DNSSEC Validation Bypass via Out-of-Zone NSEC Next Field

An attacker who knows (or guesses) that a resolver uses RPZ with wildcard CNAME policies can craft query names long enough to trigger a NAMETOOLONG error condition during RPZ processing. This is not handled correctly and may lead to defeating the RPZ rule. It also may lead to an unexpected exit of the BIND 9 software.

A malicious authoritative server can send a crafted zone via the ZoneToCache function that leads to a crash of the Recursor due to insuffcient input validation.

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.

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