Description

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.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.5",
  "pubDate": "2026-07-22T15:16:52.080Z",
  "pubdate": "2026-07-22T15:16:52.080Z",
  "executiveSummary": "This vulnerability is an assertion failure leading to a Denial of Service (DoS) affecting the BIND DNS server software. The flaw occurs during the DNSSEC validation process when handling conflicting or malformed proof of non-existence records from a parent zone. Specifically, if a provably insecure domain is covered by both NSEC and NSEC3 records at the parent, but an RRSIG exists for only one of these types, the validation logic encounters an unhandled state, causing the named process to exit unexpectedly. This presents a critical availability risk, as remote entities can trigger the crash by querying specific domains designed to exploit this parsing anomaly. The affected products include multiple stable and development branches of BIND 9, spanning versions 9.11.0 through 9.18.50, 9.20.0 through 9.20.24, 9.21.0 through 9.21.23, along with corresponding supported preview edition (S-edition) releases. Successful exploitation requires no authentication or privileges, as the trigger involves standard DNS query mechanisms processed by exposed recursive resolvers, potentially leading to continuous service disruption if automated queries target the resolver.",
  "technicalDetails": "The root cause of this vulnerability lies in the DNSSEC validation subsystem of BIND, specifically within the logic responsible for processing and verifying cryptographic proofs of non-existence. In DNSSEC, zones use either NSEC or NSEC3 records accompanied by corresponding Resource Record Signatures (RRSIG) to cryptographically prove that a requested domain name does not exist. Under normal operational standards, a zone utilizes a consistent mechanism for proving non-existence. However, if a parent zone improperly or maliciously publishes both NSEC and NSEC3 records covering a provably insecure domain, but provides an RRSIG cryptographic signature for only one of those record types, the validation state machine encounters an anomalous condition.\nThe attack flow begins when a client or an attacker initiates a standard DNS query for a target domain name that triggers this conflicting parent-side condition. The vulnerable BIND recursive resolver receives the response containing the dual NSEC and NSEC3 proofs alongside the partial signature set. As the resolver attempts to validate the cryptographic chain and process the non-existence proof, the internal validator makes assumptions regarding the completeness and mutual exclusivity of the expected signature coverage. Upon detecting the mismatch—where records exist for both types but signatures do not—the code trips an internal assertion check designed to abort execution upon encountering invalid or inconsistent internal states rather than attempting error recovery.\nThe vulnerable component is the BIND 9 validation engine handling NSEC and NSEC3 proofs. The affected versions include BIND 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. The exploitation vector is network-based, requiring the resolver to process responses originating from authoritative zones configured with the conflicting record states. No authentication, privileges, or prior system access are required to induce the failure, as any unauthenticated user capable of forcing the resolver to query the crafted zone can trigger the payload behavior. The post-exploitation impact is strictly limited to a Denial of Service via application termination (process crash), resulting in temporary or prolonged service outages for clients relying on the affected resolver depending on service manager restart configurations."
}