Introduction
ISC BIND 9 has a set of closely related assertion failures in how it handles non-Internet class DNS messages. A single unauthenticated packet can terminate a named process and take down both authoritative and recursive DNS service. BIND 9 is still the most widely deployed DNS software on the Internet, used by financial institutions, government agencies, ISPs, and universities worldwide, so any team running it in production should give CVE-2026-5946 and its CVSS 7.5 score prompt attention.
Technical information
Root cause
Multiple code paths inside named implicitly assume they are operating on Internet (IN) class data. DNS supports several class values beyond IN, including CHAOS (used historically for network topology queries and commonly for version.bind responses) and HESIOD (used in some legacy directory services). The DNS protocol also defines the meta-classes ANY and NONE for use in certain operations.
When a DNS message arrives with a non-IN class value and is routed into one of the following operations, those assumptions break:
- Recursion: The resolver logic assumes IN class throughout its processing chain.
- Dynamic updates (UPDATE): The update code processes records with IN-specific type handlers.
- Zone change notifications (NOTIFY): Notification processing does not account for non-IN class contexts.
- IN-specific record type processing: When record types that only make sense in the IN class (such as A or AAAA records) turn up in non-IN data, type confusion occurs.
Internal consistency checks then fire. These checks are C language assert() calls or ISC's equivalent REQUIRE() / INSIST() macros, and they call abort(), which terminates the named process immediately.
Weakness classification
The vulnerability maps to five CWE entries:
| CWE | Name | Role in the vulnerability |
|---|---|---|
| CWE-20 | Improper Input Validation | Non-IN class values are not filtered before they reach sensitive code paths |
| CWE-125 | Out-of-bounds Read | Memory access violations occur while parsing non-IN class record data |
| CWE-617 | Reachable Assertion | The direct crash mechanism. Assertions meant as internal guards are reachable from external input |
| CWE-754 | Improper Check for Exceptional Conditions | Meta-class values (ANY, NONE) in the question section are not handled as exceptional cases |
| CWE-843 | Type Confusion | IN-specific record type handlers process non-IN data and access resources with incompatible type expectations |
Attack flow
- The attacker identifies a target running a vulnerable version of BIND 9 (any version from 9.11.0 through 9.21.21).
- The attacker builds a DNS message with the CLASS field set to a non-IN value. For example, the QCLASS can be CHAOS (value 3), HESIOD (value 4), ANY (value 255), or NONE (value 254).
- The attacker picks a message type that reaches one of the vulnerable code paths: a standard recursive query, an UPDATE message, or a NOTIFY message.
- The attacker sends this single crafted packet to the target server over UDP or TCP on port 53.
- The
namedprocess receives the message, routes it into the affected code path, and hits a reachable assertion. - The assertion calls
abort(), and thenamedprocess terminates. DNS service stays down until the process is restarted.
The attack needs no authentication and no user interaction, and its complexity is low. Both authoritative servers and resolvers are vulnerable, so the attack surface includes essentially any BIND 9 instance that accepts DNS traffic from untrusted networks.
Patch information
ISC fixed CVE-2026-5946 in BIND 9 versions 9.18.49, 9.20.23, and 9.21.22, and in the Supported Preview Editions 9.18.49-S1 and 9.20.23-S1. The releases were published on May 20, 2026. The fix is tracked under GitLab issue GL #5784, with the commit hash 7ce6ce37b1 on the 9.18 branch.
Patch design
Rather than fix each assertion-triggering code path involving non-IN class messages one at a time, ISC took a defense-in-depth approach. It completely disabled recursion, dynamic updates (UPDATE), and zone change notifications (NOTIFY) for views whose class is anything other than IN. This is an elegant solution, because those protocol operations are Internet-class concepts. There is no legitimate operational reason to recurse or accept dynamic updates in a CHAOS or HESIOD view. Authoritative service for non-IN zones, such as serving version.bind in class CHAOS, is explicitly preserved and keeps working normally.
Additional safeguards
Beyond disabling the vulnerable operations, the patch adds two proactive safeguards.
Startup warnings and configuration checking: If a server is configured with recursion yes; inside a non-IN view, named now logs a warning at startup. named-checkconf flags the same condition, so administrators can catch and correct misconfigured zones before they are deployed.
FORMERR rejection of meta-class abuse: UPDATE and NOTIFY messages that specify the meta-classes ANY or NONE in the question section are now rejected immediately with a FORMERR (Format Error) response code. This closes a separate but closely related attack vector, in which meta-class values were processed improperly and could reach assertion-triggering code paths.
Upgrade matrix
| Affected version range | Fixed version | Availability |
|---|---|---|
| 9.18.0 through 9.18.48 | 9.18.49 | ISC Downloads |
| 9.20.0 through 9.20.22 | 9.20.23 | ISC Downloads |
| 9.21.0 through 9.21.21 | 9.21.22 | ISC Downloads |
| 9.18.11-S1 through 9.18.48-S1 | 9.18.49-S1 | Available for eligible support customers |
| 9.20.9-S1 through 9.20.22-S1 | 9.20.23-S1 | Available for eligible support customers |
Versions 9.11.0 through 9.16.50 and their corresponding S1 editions are also affected but are no longer supported. Organizations on those branches must migrate to a currently supported release.
Post-upgrade behavioral changes
The patched versions change some default behavior:
- Recursion, dynamic updates, and zone change notifications are disabled for views with a class other than IN.
- Servers configured with recursion enabled in a non-IN view log a warning at startup.
- UPDATE and NOTIFY messages that specify the ANY or NONE meta-classes are rejected with a FORMERR response.
These changes may affect monitoring baselines, so account for them during deployment.
Interim workarounds
For organizations that cannot patch immediately, ISC recommends two configuration-level mitigations: do not configure zones with a class other than IN, and do not expose servers that allow DNS Dynamic Update to the general Internet.
Affected systems and versions
These BIND 9 version ranges are confirmed vulnerable:
- 9.11.0 through 9.16.50 (end of life, no patches available, migration required)
- 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 (end of life, no patches available, migration required)
- 9.18.11-S1 through 9.18.48-S1
- 9.20.9-S1 through 9.20.22-S1
Both authoritative DNS servers and recursive resolvers running any of these versions are affected. Any unpatched named instance that accepts DNS traffic from untrusted sources is vulnerable, whether or not non-IN class zones are explicitly configured, because crafted queries alone can reach the vulnerable code paths.
Vendor security history
ISC is open about security in BIND 9. The software is open source under the MPL 2.0 license, ISC follows a rigorous vulnerability disclosure policy, and it actively supports multiple software branches at the same time.
ISC has also begun using LLM-based code analysis, which has reportedly been finding historic issues in the BIND 9 codebase. The effort has been significant enough to delay the upcoming BIND 9.22 release. CVE-2026-5946 may have been found through this review of legacy code rather than through an external report or exploitation.



