CVE-2026-77119: 
Alma Linux vulnerability analysis and mitigation

CVE-2026-77119 is a DNSSEC bypass vulnerability in ISC BIND 9 where a validly signed NSEC3 record from an unrelated sibling zone may be incorrectly accepted as an insecurity proof, allowing an attacker to downgrade a secure DNSSEC delegation and permit forged unsigned DNS answers to pass through validation. It 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, and corresponding BIND 9 Supported Preview Edition (S1) versions 9.11.3-S1 through 9.18.50-S1 and 9.20.9-S1 through 9.20.27-S1. The vulnerability was disclosed on September 16, 2026, and carries a CVSS v3.1 base score of 5.9 (Medium) (GitHub Advisory, Red Hat Bugzilla).

The root cause is an Origin Validation Error (CWE-346) combined with Authentication Bypass by Spoofing (CWE-290): BIND 9's DNSSEC validation logic fails to verify that an NSEC3 record used as an insecurity proof actually belongs to the zone being validated, rather than an unrelated sibling zone. An attacker positioned to inject or intercept DNS responses can supply a legitimately signed NSEC3 record from a sibling zone to convince the resolver that a secure delegation is actually insecure (an "insecure referral" proof), causing it to accept a forged, unsigned DNS answer. Exploitation requires high attack complexity — the attacker must be able to supply or intercept DNS responses in a position to present the crafted NSEC3 record — and no authentication or user interaction is needed (GitHub Advisory, Red Hat Bugzilla, ISC KB).

Successful exploitation allows an unauthenticated network attacker to bypass DNSSEC validation, effectively downgrading a cryptographically secured DNS delegation to an insecure one and injecting forged DNS responses. This enables DNS spoofing attacks that can redirect users to malicious infrastructure, intercept communications, or facilitate phishing and man-in-the-middle attacks against services relying on DNSSEC for integrity assurance. There is no confidentiality or availability impact directly from the vulnerability itself, but the integrity of DNS resolution is fully compromised for affected queries (GitHub Advisory, ISC KB).

There is no public proof-of-concept exploit and no evidence of in-the-wild exploitation as of the disclosure date (ISC KB). The EPSS score is 0.0, reflecting a currently low probability of exploitation in the near term. The vulnerability is not listed in the CISA Known Exploited Vulnerabilities catalog. Exploitation requires high attack complexity, as the attacker must be able to supply a crafted NSEC3 record from a sibling zone during DNS resolution, limiting the practical attacker pool (GitHub Advisory).

1. Reconnaissance: Identify target resolvers running vulnerable BIND 9 versions (9.11.0–9.18.50, 9.20.0–9.20.27, 9.21.0–9.21.25, or corresponding S1 versions) that perform DNSSEC validation.
2. Identify target delegation: Select a DNSSEC-secured domain delegation (e.g., secure.example.com) that the target resolver is expected to validate.
3. Obtain a valid sibling NSEC3 record: Acquire or generate a legitimately signed NSEC3 record from an unrelated sibling zone (e.g., sibling.example.com) that shares the same parent zone, ensuring it is cryptographically valid.
4. Intercept or inject DNS response: Position to intercept the resolver's query for the target delegation (e.g., via a man-in-the-middle attack on the DNS path, a rogue authoritative server, or DNS cache poisoning of the parent zone).
5. Supply crafted NSEC3 as insecurity proof: Return the sibling zone's NSEC3 record in the DNS response as a proof of insecurity for the target delegation, causing the vulnerable BIND 9 resolver to treat the secure delegation as insecure.
6. Inject forged unsigned answer: With DNSSEC validation bypassed, supply a forged unsigned DNS answer for the target domain, redirecting resolution to an attacker-controlled IP address (ISC KB, GitHub Advisory).

• Network: Unexpected NSEC3 records in DNS responses that belong to a different zone than the one being queried; DNS responses for DNSSEC-secured domains arriving without RRSIG records where they are expected.
• Logs: BIND 9 resolver logs showing DNSSEC validation succeeding for delegations that should be secure but are being treated as insecure; unexpected insecurity proof log entries referencing NSEC3 records from unrelated zones.
• DNS Traffic: Queries for known DNSSEC-signed domains resolving to unexpected IP addresses; absence of the AD (Authenticated Data) flag in resolver responses for domains that should have it set.

ISC has released patched versions BIND 9.20.29 and 9.21.26 that address this vulnerability; administrators should upgrade to these versions as the primary remediation (ISC KB, GitHub Advisory). As a network-level workaround, implement network segmentation to restrict DNS query sources and limit exposure of recursive resolvers to untrusted networks. No configuration-based workaround within BIND 9 itself has been published; upgrading is the recommended and definitive fix.

ISC published a knowledge base article and coordinated disclosure on September 16, 2026, describing the issue as part of a batch of 14 BIND 9 vulnerabilities patched in versions 9.20.29 and 9.21.26 (Linux Compatible). Red Hat opened a security response bug (BZ#2535469) and assigned medium severity, with 17 users CC'd indicating active internal triage (Red Hat Bugzilla). The vulnerability was also discussed on the oss-security mailing list shortly after disclosure.