CVE-2026-5946

What it actually does

CVE-2026-5946 is a remotely reachable denial-of-service flaw in ISC BIND 9's `named` daemon. The vulnerable code incorrectly handles DNS messages with non-Internet classes such as `CHAOS` or `HESIOD`, meta-classes such as `ANY` or `NONE` in the question section, or Internet-specific record types embedded in non-`IN` data. When specially crafted packets reach affected code paths, including recursion, dynamic update processing, zone change notifications, or class-specific record handling, `named` can hit assertion failures and terminate. The primary technical effect is loss of DNS service availability; the issue does not provide confidentiality or integrity impact by itself.

Why it matters to the business

Successful exploitation can crash an affected BIND DNS server, interrupting name resolution or authoritative DNS service for dependent applications, users, and network infrastructure. Because DNS is a foundational service, outages may appear as broad application downtime, failed logins, email delivery issues, degraded internal connectivity, or public service unreachability. The CVSS score of 7.5 reflects high availability impact with low attack complexity and no authentication requirement, but the currently reported EPSS is low and the issue is not listed in CISA KEV, suggesting no confirmed broad exploitation at this time. Organizations that expose recursive, authoritative, dynamic update, or NOTIFY-capable BIND servers to untrusted networks should treat remediation as a priority because exploitation requires only crafted DNS traffic.

How an attack unfolds

An attacker first identifies a reachable BIND 9 `named` service, typically on UDP or TCP port 53. They then send crafted DNS messages that use a non-`IN` class, a meta-class such as `ANY` or `NONE`, or otherwise combine `IN`-specific record handling with non-`IN` class data. Depending on the exposed role of the server, the packet may be directed at the recursive resolver path, dynamic update handling, NOTIFY processing, or authoritative record parsing. If the vulnerable code path is reached, `named` triggers an internal assertion failure and exits or restarts, causing DNS resolution or authoritative service interruption until the service manager restarts it or an administrator intervenes. Repeated requests can sustain a denial-of-service condition.

How to fix it

Upgrade ISC BIND 9 to a vendor-fixed release when available from ISC or the operating system/package vendor. The affected ranges are BIND 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, BIND Supported Preview Edition 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. If an immediate upgrade is not possible, reduce exposure by restricting recursive service to trusted clients, disabling or tightly ACLing dynamic updates, accepting NOTIFY only from expected authoritative peers, filtering unsolicited DNS traffic at network boundaries, and ensuring `named` is supervised by a service manager for automatic restart. Avoid relying on restart alone as a fix, because repeated packets can re-trigger the crash.

How to confirm the fix worked

Confirm the installed BIND version is outside the affected ranges or that the distribution package includes the vendor backport for this issue. Use commands such as `named -v`, package manager queries, or vendor advisory metadata to verify the effective patched build. Review `named.conf` and included configuration files to confirm recursion, `allow-recursion`, `allow-query-cache`, `allow-update`, `allow-notify`, and `also-notify` are limited to trusted sources where appropriate. Validate that UDP and TCP port 53 exposure matches the server role and is not unnecessarily reachable from untrusted networks. After patching or mitigation, monitor for absence of new assertion failures, unexpected `named` restarts, core dumps, or service-manager restart loops during normal DNS traffic.

Typical attack path

1. Discover an exposed ISC BIND `named` service on UDP/TCP port 53.
2. Determine whether the server provides recursion, authoritative service, dynamic update handling, or zone notification processing reachable from the attacker.
3. Craft DNS packets using non-Internet classes such as `CHAOS` or `HESIOD`, meta-classes such as `ANY` or `NONE`, or class/record-type combinations that reach vulnerable handling logic.
4. Send the crafted DNS request, UPDATE, or NOTIFY message to the target server.
5. Trigger an assertion failure in `named`, causing the daemon to terminate or restart.
6. Repeat the crafted traffic to prolong DNS service disruption.

How to detect it

To determine whether exploitation may already have occurred, review BIND logs, system logs, service-manager journals, crash dumps, and network telemetry around DNS service interruptions. Focus on unexpected `named` exits, assertion failures, abort signals, core dumps, and rapid restart loops. In BIND logging, inspect `general`, `security`, `queries`, `update`, and `notify` channels if enabled. Look for unusual DNS messages shortly before a crash, especially queries or control messages using classes other than `IN`, such as `CH`/`CHAOS` or `HS`/`HESIOD`, meta-classes `ANY` or `NONE`, dynamic update attempts from untrusted sources, or NOTIFY messages from unexpected peers. Network captures or DNS telemetry may show malformed or uncommon class values immediately before the daemon terminates. Because no public exploit-specific payload or named threat actor activity is provided, detection should emphasize behavioral crash evidence correlated with anomalous DNS class usage and unsolicited UPDATE or NOTIFY traffic.

• named: assertion failure
• named: assertion failed
• named[
• exiting due to assertion failure
• received signal 6
• SIGABRT
• core dumped
• systemd-coredump
• named.service: Main process exited
• named.service: Failed with result 'core-dump'
• named.service: Scheduled restart job
• named.service: Start request repeated too quickly
• client @0x
• query:
• class CH
• class CHAOS
• class HS
• class HESIOD
• class ANY
• class NONE
• opcode UPDATE
• opcode NOTIFY
• denied update from
• zone transfer deferred due to quota

What your security team should do

• Inventory all ISC BIND `named` deployments, including recursive resolvers, authoritative servers, hidden masters, secondaries, and appliances or distributions that embed BIND.
• Prioritize patching Internet-facing or untrusted-network-facing BIND servers running versions in the affected ranges.
• Apply vendor-provided fixed packages or upgrade to a non-affected BIND release as soon as available; track OS vendor backports rather than relying only on upstream version strings.
• Restrict recursion, dynamic updates, and NOTIFY handling to trusted clients and peers using BIND ACLs and network controls.
• Ensure `named` runs under a service manager with restart limits and alerting so crashes are detected quickly without masking repeated exploitation attempts.
• Enable and centralize BIND logs for queries, security events, update events, notify events, and general daemon failures where operationally feasible.
• Create SIEM alerts for `named` assertion failures, unexpected exits, core dumps, and repeated restarts.
• Monitor external threat reporting for proof-of-concept publication or EPSS increases, and escalate remediation urgency if exploitation emerges.