CVE-2026-5950

What it actually does

This vulnerability affects the BIND 9 recursive resolver state machine. Under specific bad-server retry conditions, the resolver can enter an unbounded resend loop instead of stopping or backing off correctly. A remote unauthenticated attacker can trigger this behavior by sending DNS queries to an exposed affected resolver, causing excessive CPU, memory, socket, or network resource consumption. The impact is availability-focused: confidentiality and integrity are not directly affected, but recursive DNS resolution can become slow, unstable, or unavailable.

Why it matters to the business

Organizations that rely on affected BIND resolvers may experience DNS outages or severe latency, which can make internal and external applications appear unavailable even when those applications are otherwise healthy. Because DNS is a dependency for authentication, web access, email, service discovery, updates, monitoring, and cloud connectivity, operational impact can be broad. The issue is remotely reachable, requires no authentication, and has low attack complexity, but it is not currently listed in CISA KEV and the provided EPSS score is low, suggesting no strong public exploitation signal at this time.

How an attack unfolds

An attacker first identifies a BIND 9 recursive resolver running an affected version and reachable over UDP or TCP port 53. The attacker then sends DNS queries designed to trigger resolver retry behavior involving servers marked as bad or otherwise failing. In vulnerable versions, this handling can cause the resolver to repeatedly resend queries without a proper bound. As the loop continues, the named process consumes increasing resources and may generate elevated outbound DNS traffic. With enough malicious queries or sustained traffic, legitimate DNS lookups are delayed, fail with SERVFAIL or timeouts, or the resolver process becomes unstable, resulting in a denial of service.

How to fix it

Upgrade affected BIND 9 deployments to a fixed release newer than the vulnerable ranges: later than 9.18.48, later than 9.20.22, later than 9.21.21, later than 9.18.48-S1, or later than 9.20.22-S1, as applicable for the branch in use. If an immediate upgrade is not possible, reduce exposure by ensuring recursive service is not open to the Internet, restricting recursion with allow-recursion and allow-query-cache ACLs, filtering access to port 53 at network boundaries, using response rate limiting where appropriate, and monitoring resolver resource usage. Run authoritative-only and recursive resolver functions separately where possible so a resolver DoS does not affect authoritative DNS service.

How to confirm the fix worked

Confirm the installed BIND version using named -V, package-manager inventory, container image metadata, or appliance firmware version information, and verify it is outside the affected version ranges. Review named.conf to ensure recursion is restricted to trusted clients and that public-facing authoritative servers do not offer open recursion. Validate from an untrusted network that recursive queries are refused. After patching, monitor named CPU, memory, file descriptors, query latency, SERVFAIL rates, and outbound recursive query volume under normal and test load to confirm stability. Where feasible, perform controlled DNS resolver testing in a non-production environment to ensure malformed or failure-inducing query patterns no longer produce runaway retry behavior.

Typical attack path

1. Identify an exposed recursive DNS resolver running ISC BIND 9.
2. Confirm that recursion is available to the attacker or to a reachable client path.
3. Send DNS queries that induce bad-server retry handling in the resolver.
4. Trigger the vulnerable unbounded resend loop in the resolver state machine.
5. Sustain or repeat the query pattern to consume resolver CPU, memory, sockets, or outbound network capacity.
6. Cause legitimate DNS resolution to slow, fail, or become unavailable.

How to detect it

There is no single vulnerability-specific log string or payload known from the provided information. To assess possible prior exploitation, review BIND query logs, resolver/debug logs, dnstap captures, syslog or journald entries for named, NetFlow or firewall telemetry for UDP/TCP 53, and host metrics for the named process. Look for time-correlated spikes in recursive queries from a small number of sources, repeated queries for unusual or newly observed domains, elevated outbound DNS traffic to upstream or authoritative servers, sharp increases in SERVFAIL or timeout responses, and named CPU, memory, file descriptor, or socket exhaustion. Also review service restarts, watchdog kills, OOM events, and DNS latency alerts. Because exploitation causes denial of service rather than code execution, investigation should focus on resource-exhaustion patterns and malicious query sources rather than persistence artifacts.

What your security team should do

• Inventory all BIND 9 recursive resolvers, including appliances, containers, and downstream packages that embed ISC BIND.
• Prioritize upgrades for Internet-reachable or broadly reachable recursive resolvers running versions 9.18.36-9.18.48, 9.20.8-9.20.22, 9.21.7-9.21.21, 9.18.36-S1-9.18.48-S1, or 9.20.9-S1-9.20.22-S1.
• Restrict recursion to trusted client networks and verify that no resolver is operating as an open recursive DNS service.
• Add monitoring and alerting for named resource exhaustion, spikes in recursive query retries, elevated SERVFAIL/timeouts, and abnormal outbound DNS traffic.
• Review DNS service resilience, including redundant resolvers, health checks, and failover behavior, because exploitation can affect availability rather than data confidentiality.
• If patching is delayed, apply compensating controls at firewalls, load balancers, and DNS access-control lists to limit who can reach recursive service.