Internet Systems Consortium (ISC) has released security updates for BIND 9 that remediate three significant vulnerabilities in the recursive resolver. Two bugs open paths for DNS cache poisoning and one enables denial of service. Patched builds are available in 9.18.41, 9.20.15, and 9.21.14; the BIND Supported Preview Edition (SPE) is updated to 9.18.41‑S1 and 9.20.15‑S1. Administrators should update promptly and flush resolver caches after deployment.
BIND 9 security update: what was fixed
CVE-2025-40780 (CVSS 8.6): predictable source port and transaction ID
A defect in the pseudo‑random number generator can, under certain conditions, make the outgoing source port and transaction ID (TXID) of DNS queries more predictable. Port and TXID randomization have been core defenses against cache poisoning since the 2008 Kaminsky attack. If an off‑path attacker can time spoofed responses correctly, the resolver may accept and cache a forged answer, redirecting clients to attacker‑controlled destinations.
CVE-2025-40778 (CVSS 8.6): overly permissive response processing
The resolver insufficiently validates records received in responses, allowing injection of fake resource records into the DNS cache. Successful exploitation enables an attacker to influence name resolution for all clients using the affected recursive server.
CVE-2025-8677 (CVSS 7.5): denial of service via malformed DNSKEY
Queries involving zone data with specially crafted, malformed DNSKEY records can drive elevated CPU usage, leading to performance degradation or service unavailability. This is a classic resource‑exhaustion DoS that targets validation paths.
Impact and real‑world risk
The vulnerabilities affect recursive resolvers; authoritative‑only BIND servers are not impacted by these issues. Vendor guidance indicates that CVE‑2025‑40780 is non‑trivial to exploit: an attacker must perform precise network spoofing and win a race against legitimate replies. The immediate consequence is compromise of cache integrity rather than full system compromise, but the impact on users can be severe (e.g., credential phishing, malware distribution) if forged answers are cached.
Defense‑in‑depth controls remain effective. DNSSEC validation prevents acceptance of unsigned or improperly signed data, blocking most cache‑poisoning scenarios. Response rate limiting (RRL) curbs abuse, while properly configured firewalls and anti‑spoofing filters (BCP 38/84) reduce the feasibility of off‑path spoofing. These recommendations align with guidance from ISC advisories and Linux distribution security teams.
Recommended actions for DNS administrators
1) Patch immediately: upgrade to 9.18.41, 9.20.15, or 9.21.14 (SPE: 9.18.41‑S1/9.20.15‑S1). After upgrading, flush the cache (rndc flush) to remove any potentially injected entries.
2) Enforce DNSSEC: enable validation, maintain a current root trust anchor, and monitor validation failures. DNSSEC substantially lowers the likelihood of successful cache poisoning.
3) Harden recursion: restrict recursive service via ACLs to trusted networks, enable RRL, use qname‑minimization, and ensure port and TXID randomization remain enabled.
4) Implement network anti‑spoofing: apply BCP 38/84 source address validation at network edges and control egress/ingress to hinder spoofed traffic reaching resolvers.
5) Monitor and respond: increase DNS logging granularity, alert on spikes in NXDOMAIN/ServFail and on unusual CPU usage, and periodically test cache integrity to catch poisoning attempts early.
Related note: similar findings in Unbound
The researchers who reported the BIND issues identified related weaknesses in Unbound as well, with a lower overall risk (CVSS 5.6). Operators of mixed resolver environments should align patching and configuration hardening across all DNS components to maintain consistent security posture.
Rapidly applying the latest BIND 9 updates, enforcing strict response validation, and running DNSSEC are practical, high‑value steps to reduce risk. Verify resolver versions, tighten ACLs, enable RRL and anti‑spoofing at the perimeter, and monitor for anomalies. A disciplined patch and monitoring routine remains the most effective way to prevent cache poisoning and keep critical services available.
