CVE-2026-3592

What it actually does

The flaw allows a remote, unauthenticated attacker to trigger disproportionate CPU, memory, or resolver-state consumption in affected BIND recursive resolvers by causing them to query a specially crafted DNS zone. The vulnerability affects 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, and corresponding Supported Preview Edition ranges. Successful exploitation primarily impacts availability: recursive resolution may slow down, exhaust internal quotas, return SERVFAIL/timeouts, or make the named process unstable under load. The CVSS score is moderate, the EPSS score is low and stable, and there is no current KEV listing or known public exploit maturity indicated in the supplied data.

Why it matters to the business

Organizations relying on affected BIND resolvers could experience DNS degradation or outages, which can make websites, internal applications, authentication flows, email delivery, software updates, and cloud integrations appear unavailable even when the underlying services are healthy. Because DNS is a dependency for many business processes, a resolver exhaustion event can cause broad operational disruption. Current exploitation signals are low based on the supplied EPSS, no KEV status, and no known exploit maturity, but Internet-facing recursive resolvers or resolvers reachable by large user populations should still be prioritized because DoS vulnerabilities can be triggered remotely and may be difficult to distinguish from traffic surges without DNS telemetry.

How an attack unfolds

An attacker first identifies or gains the ability to influence clients that use an affected BIND recursive resolver. The attacker then causes the resolver to issue DNS lookups for names in a specially crafted zone under the attacker's control or prepared infrastructure. When the resolver processes the crafted zone data and related resolution behavior, it consumes more resources than a normal query should require. By repeating or distributing these lookups, the attacker amplifies resource consumption until resolver capacity is degraded, recursive-client limits are hit, query latency rises, or the named process becomes resource constrained. The visible result is availability loss for users and systems depending on that resolver, commonly seen as DNS timeouts, SERVFAIL responses, or intermittent name-resolution failures.

How to fix it

Upgrade affected BIND installations to a vendor-fixed release newer than the affected ranges listed in the advisory. Because exact fixed versions were not provided in the input, obtain the current ISC security advisory and install the first fixed release for the deployed maintenance branch, or move to the latest supported BIND release available from ISC or the operating-system vendor. Affected ranges include 9.11.0-9.16.50, 9.18.0-9.18.48, 9.20.0-9.20.22, 9.21.0-9.21.21, 9.11.3-S1-9.16.50-S1, 9.18.11-S1-9.18.48-S1, and 9.20.9-S1-9.20.22-S1. As interim mitigation, restrict recursive resolver access to trusted clients only, block open recursion from the Internet, rate-limit abusive clients where operationally safe, tune recursive-client and fetch limits according to capacity, use upstream DNS filtering where appropriate, and ensure resolver monitoring can alert on resource exhaustion. Restart named only as a temporary recovery action; it does not remediate the vulnerable code path.

How to confirm the fix worked

Confirm exposure by inventorying BIND versions with named -v, package-manager metadata, container image manifests, or configuration-management inventory and comparing them with the affected version ranges. Confirm remediation by verifying that all recursive resolvers run a vendor-fixed version outside the affected ranges and that the active named binary is the patched binary, not only an installed but inactive package. Validate resolver configuration to ensure recursion is not open to untrusted networks using allow-recursion, allow-query-cache, ACLs, and network firewall rules. After patching, monitor DNS latency, SERVFAIL rate, recursive-client usage, memory consumption, CPU utilization, and named process stability during normal traffic and controlled internal testing. Review BIND statistics-channel metrics, system telemetry, and DNS query logs to confirm that resource usage remains stable under representative recursive-query load.

Typical attack path

1. Identify an organization using an affected BIND 9 recursive resolver version.
2. Prepare or control a DNS zone designed to trigger disproportionate resolver resource consumption.
3. Send DNS queries directly to the resolver if it is reachable, or induce downstream clients to request names in the crafted zone.
4. Repeat the query pattern to increase CPU, memory, socket, or recursive-client pressure on the resolver.
5. Cause resolver degradation, quota exhaustion, high latency, SERVFAIL responses, or process instability.
6. Maintain pressure long enough to disrupt dependent applications and business services.

How to detect it

To determine whether exploitation may already have occurred, review BIND named logs, DNS query logs, resolver statistics-channel data, operating-system resource telemetry, and network flow records for periods of unexplained resolver degradation. Look for spikes in queries to newly seen or low-reputation domains, repeated lookups into the same unusual zone, increases in SERVFAIL or timeout responses, growth in recursive-client usage, high fetch counts, and CPU or memory saturation of the named process. Correlate DNS symptoms with client source IPs, queried zones, and timestamps to distinguish a vulnerability-triggering query pattern from normal traffic growth. Review system logs for named restarts, OOM-killer activity, crashes, or fatal errors. If available, compare query-name distribution before and during the incident and identify domains whose requests immediately precede resource exhaustion. There are no supplied named threat actors, KEV exploitation, ransomware linkage, or public exploit indicators; detection should therefore focus on behavioral evidence of recursive resolver exhaustion rather than a single known payload string.

• no more recursive clients: quota reached
• recursive-clients quota reached
• clients-per-query increased
• clients-per-query decreased
• too many timeouts resolving
• SERVFAIL
• named
• named.service: Main process exited
• named.service: Failed with result
• Out of memory: Killed process
• oom-killer
• exiting (due to fatal error)

What your security team should do

• Inventory all BIND recursive resolvers, including appliances, containers, embedded DNS services, and operating-system packaged deployments.
• Prioritize patching Internet-facing resolvers, shared enterprise resolvers, and resolvers serving critical authentication, application, or production networks.
• Upgrade BIND to a vendor-fixed release or latest supported package for the deployed branch; track operating-system vendor backports where version strings may not visibly change to upstream fixed versions.
• Verify that recursion is restricted to trusted clients and that no affected resolver is operating as an open recursive resolver.
• Enable or review BIND statistics, query logging where feasible, resolver health metrics, and alerting for recursive-client quota exhaustion, SERVFAIL spikes, high latency, and named CPU or memory saturation.
• Create detection logic for abnormal query bursts toward unusual domains or zones followed by resolver resource exhaustion symptoms.
• Prepare an operational runbook for DNS DoS events, including traffic filtering, temporary client blocking, resolver failover, cache warm-up, and escalation to network teams or upstream providers.
• Because the issue is not currently listed in KEV and EPSS is low and stable, treat it as a scheduled but important infrastructure patch unless local exposure is Internet-facing or resolver capacity is already constrained.