Excessive NSEC3 iterations cause high CPU load during insecure delegation validation

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.

In ISC BIND9 versions BIND 9.11.14 -> 9.11.19, BIND 9.14.9 -> 9.14.12, BIND 9.16.0 -> 9.16.3, BIND Supported Preview Edition 9.11.14-S1 -> 9.11.19-S1: Unless a nameserver is providing authoritative service for one or more zones and at least one zone contains an empty non-terminal entry containing an asterisk ("") character, this defect cannot be encountered. A would-be attacker who is allowed to change zone content could theoretically introduce such a record in order to exploit this condition to cause denial of service, though we consider the use of this vector unlikely because any such attack would require a significant privilege level and be easily traceable.

A flaw was found in the Bind package, where the DNSSEC verification code for the EdDSA algorithm leaks memory when there is a signature length mismatch. By spoofing the target resolver with responses that have a malformed EdDSA signature, an attacker can trigger a small memory leak, resulting in crashing the program.

A flaw was found in the Bind package. By spoofing the target resolver with responses that have a malformed ECDSA signature, an attacker can trigger a small memory leak, resulting in crashing the program.

A flaw was found in bind. When flooding the target resolver with special queries, an attacker can significantly impair the resolver's performance, effectively denying legitimate clients access to the DNS resolution service.

"managed-keys" is a feature which allows a BIND resolver to automatically maintain the keys used by trust anchors which operators configure for use in DNSSEC validation. Due to an error in the managed-keys feature it is possible for a BIND server which uses managed-keys to exit due to an assertion failure if, during key rollover, a trust anchor's keys are replaced with keys which use an unsupported algorithm. Versions affected: BIND 9.9.0 -> 9.10.8-P1, 9.11.0 -> 9.11.5-P1, 9.12.0 -> 9.12.3-P1, and versions 9.9.3-S1 -> 9.11.5-S3 of BIND 9 Supported Preview Edition. Versions 9.13.0 -> 9.13.6 of the 9.13 development branch are also affected. Versions prior to BIND 9.9.0 have not been evaluated for vulnerability to CVE-2018-5745.

Invalid handling of CLASS != IN

A specially crafted domain can be used to cause a memory leak in a BIND resolver simply by querying this domain. This issue affects BIND 9 versions 9.20.0 through 9.20.20, 9.21.0 through 9.21.19, and 9.20.9-S1 through 9.20.20-S1. BIND 9 versions 9.18.0 through 9.18.46 and 9.18.11-S1 through 9.18.46-S1 are NOT affected.

BIND 9 server memory exhaustion during GSS-API TKEY negotiation

Last updated 22 May 2026

A use-after-free vulnerability exists within the DNS-over-HTTPS implementation. This issue affects BIND 9 versions 9.20.0 through 9.20.22, 9.21.0 through 9.21.21, and 9.20.9-S1 through 9.20.22-S1. BIND 9 versions 9.18.0 through 9.18.48 and 9.18.11-S1 through 9.18.48-S1 are NOT affected.

Cache poisoning attacks with unsolicited RRs

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.

BIND servers that are configured to use TKEY-based authentication via GSS-API tokens are vulnerable to excessive memory consumption when receiving and processing maliciously-constructed packets. Typically these servers will be found in Active Directory integrated DNS deployments and/or Kerberos-secured DNS environments.

Undefined behavior may result due to a race condition leading to a use-after-free violation. If BIND receives an incoming DNS message signed with SIG(0), it begins work to validate that signature. If, during that validation, the "recursive-clients" limit is reached (as would occur during a query flood), and that same DNS message is discarded per the limit, there is a brief window of time while the SIG(0) validation may attempt to read the now-discarded DNS message.

Querying for records within a specially crafted zone containing certain malformed DNSKEY records can lead to CPU exhaustion.

In specific circumstances, due to a weakness in the Pseudo Random Number Generator (PRNG) that is used, it is possible for an attacker to predict the source port and query ID that BIND will use.

Under certain circumstances, BIND is too lenient when accepting records from answers, allowing an attacker to inject forged data into the cache.

Description: Clients using DNS-over-HTTPS (DoH) can exhaust a DNS resolver's CPU and/or memory by flooding it with crafted valid or invalid HTTP/2 traffic.

Impact: By flooding a target resolver with HTTP/2 traffic and exploiting this flaw, an attacker could overwhelm the server, causing high CPU and/or memory usage and preventing other clients from establishing DoH connections. This would significantly impair the resolver's performance and effectively deny legitimate clients access to the DNS resolution service.

Authoritative servers are affected by this vulnerability. Resolvers are affected by this vulnerability.

Versions affected: 9.18.0 -> 9.18.32 9.20.0 -> 9.20.4 9.21.0 -> 9.21.3

(Versions prior to 9.18.27 were not assessed.)

Resolver caches and authoritative zone databases that hold significant numbers of RRs for the same hostname (of any RTYPE) can suffer from degraded performance as content is being added or updated, and also when handling client queries for this name. This vulnerability affects the following bind versions: 9.11.0 -> 9.11.37 9.16.0 -> 9.16.50 9.18.0 -> 9.18.27 9.19.0 -> 9.19.24

dhcpd: use-after-free error leads crash in IPv6 mode when using mismatched BIND libraries

BIND resolvers are vulnerable to an amplified resource consumption/exhaustion attack. If a victim resolver makes a query to a specially crafted zone, the resolver will consume disproportionate resources. This issue affects BIND 9 versions 9.11.0 through 9.16.50, 9.18.0 through 9.18.48, 9.20.0 through 9.20.22, 9.21.0 through 9.21.21, 9.11.3-S1 through 9.16.50-S1, 9.18.11-S1 through 9.18.48-S1, and 9.20.9-S1 through 9.20.22-S1.

An unbounded resend loop vulnerability exists in the BIND 9 resolver state machine during bad-server handling, enabling a remote unauthenticated attacker to cause severe resource exhaustion by sending queries that trigger specific retry conditions. This issue affects BIND 9 versions 9.18.36 through 9.18.48, 9.20.8 through 9.20.22, 9.21.7 through 9.21.21, 9.18.36-S1 through 9.18.48-S1, and 9.20.9-S1 through 9.20.22-S1.

An attacker able to send and receive messages to an authoritative DNS server may be able to circumvent TSIG authentication of AXFR requests via a carefully constructed request packet. A server that relies solely on TSIG keys for protection with no other ACL protection could be manipulated into:

providing an AXFR of a zone to an unauthorized recipient accepting bogus Notify packets

An unauthorized AXFR (full zone transfer) permits an attacker to view the entire contents of a zone. Protection of zone contents is often a commercial or business requirement.

If accepted, a Notify sets the zone refresh interval to 'now'. If there is not already a refresh cycle in progress then named will initiate one by asking for the SOA RR from its list of masters. If there is already a refresh cycle in progress, then named will queue the new refresh request. If there is already a queued refresh request, the new Notify will be discarded. Bogus notifications can't be used to force a zone transfer from a malicious server, but could trigger a high rate of zone refresh cycles.

Workarounds:

The effects of this vulnerability can be mitigated by using Access Control Lists (ACLs) that require both address range validation and use of TSIG authentication in parallel. For information on how to configure this type of compound authentication control, please see:

https://kb.isc.org/article/AA-00723/0/Using-Access-Control-Lists-ACLs-with-both-addresses-and-keys.html.

(Note that this technique will not be effective against bogus Notify packets if an attacker is able to reach the target DNS server whilst using a spoofed sending address).

Upstream patch:

https://source.isc.org/cgi-bin/gitweb.cgi?p=bind9.git;a=commitdiff;h=581c1526ab

Last updated 24 July 2024

An attacker who is permitted to send zone data to a server via zone transfer can exploit this to intentionally trigger the assertion failure with a specially constructed zone, denying service to clients.

It was reported that a defect in how BIND handled queries for NSEC3-signed zones could cause a crash of the named daemon with an "INSIST" failure when processing queries that possessed certain properties.

A remote attacker could exploit this defect by constructing a carefully-crafted query against an authoritative nameserver that served NSEC3-signed zones.

Note that this flaw affects BIND versions 9.6.0 and higher (NSEC3 was introduced in BIND 9.6.0 but is not automatically enabled). Authoritative nameservers that are serving at least one NSEC3-signed zone are vulnerable. Authoritative nameservers that are NOT serving at least one NSEC3-signed zone are not vulnerable, nor are recursive-only servers. Servers running versions of BIND older than 9.6.0 are also not vulnerable.

There are no workarounds for this issue.

The Winsock WSAIoctl API in Microsoft Windows Server 2008, as used in ISC BIND 9.6-ESV before 9.6-ESV-R10-P1, 9.8 before 9.8.6-P1, 9.9 before 9.9.4-P1, 9.9.3-S1, 9.9.4-S1, and other products, does not properly support the SIOGETINTERFACELIST command for netmask 255.255.255.255, which allows remote attackers to bypass intended IP address restrictions by leveraging misinterpretation of this netmask as a 0.0.0.0 netmask.

Internet Systems Consortium (ISC) BIND 9.6.0 and earlier does not properly check the return value from the OpenSSL EVPVerifyFinal function, which allows remote attackers to bypass validation of the certificate chain via a malformed SSL/TLS signature, a similar vulnerability to CVE-2008-5077 and CVE-2009-0025.