On October 8, 2026, CISA added BIND flaw CVE-2015-5477 to its Known Exploited Vulnerabilities catalog. A crafted TKEY query can cause named to exit on a vulnerable DNS server even when its operator restricts clients with access controls. Operators of affected resolvers and authoritative servers have an October 11 federal action date. The KEV addition puts this 2015 denial-of-service bug back on the patch list for anyone still running a vulnerable build.
CISA says the remote TKEY query can cause a denial of service. Losing a resolver interrupts clients’ name lookups; losing an authoritative server interrupts answers for the zones it serves. An outage in either role can spread into application failures that look unrelated to DNS at first. Prioritize the machines actually serving DNS, including vendor-packaged copies of BIND.
TKEY processing precedes access controls
The ISC advisory by Michael McNally says a constructed packet targeting TKEY record handling triggers a REQUIRE assertion failure and exits the named process. ISC’s description is blunt: “Both recursive and authoritative servers are vulnerable to this defect.” The defective handler runs before the checks that enforce access-control lists and service-limiting configuration. A restrictive ACL therefore cannot substitute for a fixed build on a reachable DNS server.
The advisory covered BIND 9.1.0 through the 9.8.x line, the 9.9 line through 9.9.7-P1, and the 9.10 line through 9.10.2-P2. ISC listed no workaround and released 9.9.7-P2 and 9.10.2-P3 as patched versions. Its July 2015 advisory said active exploits were “None known” at that time; CISA’s October 2026 KEV addition changes the current priority. Jonathan Foote discovered and disclosed the defect, according to ISC.
Distributor builds need their own check
Red Hat’s RHSA-2015:1513 advisory supplied corrected BIND packages for Red Hat Enterprise Linux 6 and 7. Its examples include bind-9.8.2-0.37.rc1.el6_7.2 for RHEL 6 and bind-9.9.4-18.el7_1.3 for RHEL 7. Those upstream-looking version prefixes remain lower than ISC’s patched release numbers because Red Hat backported the fix. Compare a distribution package with its own security erratum, rather than marking it vulnerable solely by an upstream version string. Red Hat says installing the update automatically restarts named; plan for that brief DNS-service interruption.
Find running BIND instances in DNS server inventories and verify the installed build or vendor package against the applicable fix. The machine’s actual named process and installed package are the targets of the check, including any appliance or managed image that bundles BIND. For the ISC release lines above, move to a vendor-supported patched release. For Red Hat packages, use the distributor’s corrected advisory package or a subsequent vendor-confirmed update. If mitigations are unavailable, CISA’s required action calls for discontinuing use of the affected product. Do not rely on an ACL-only change for this flaw.
Verify DNS service after updating
Capture the installed named build and its package provenance before the change. On systems using the standard BIND binary, named -v reports that binary’s version family; confirm it is the executable used by the running service. On an RPM-based installation, rpm -q bind identifies the installed package release to compare with the vendor erratum. Check the service manager’s named status and its logs for abrupt exits or a REQUIRE assertion as you review prior outages. A crash can have other causes, so use the packet or incident evidence available to your team before attributing an old interruption to this CVE.
Install the corrected build and check the service again after its restart. From an existing monitoring point, confirm the resolver returns a normal answer for a known internal name or the authoritative server answers for one of its zones, according to the role it actually serves. The expected result is a running named process, an installed vendor-confirmed fixed package, and successful DNS answers on the normal service path.