Security Digest · Jul 28, 2015 · Vulnerability · Network edge

BIND CVE-2015-5477: 2015 TKEY DNS Crash Bug Now in KEV

One crafted query crashes BIND 9 before 9.9.7-P2/9.10.2-P3. In CISA KEV since Oct 2026, tied to a China-linked campaign advisory. Check old DNS boxes.

Our verdict

Check exposure

Any BIND release from the past decade is fixed, so most teams have nothing to do; the real risk is forgotten DNS servers and appliances still running pre-mid-2015 BIND, which one packet can knock offline.

Who must act: Operators of BIND 9 builds older than 9.9.7-P2 or 9.10.2-P3, including old Linux servers, appliances and network devices that embed BIND, especially ones that answer DNS from the internet.

Who can relax: Anyone on a BIND release from August 2015 or later, distro packages patched since then, other DNS servers (Unbound, PowerDNS, dnsmasq), and teams using managed DNS.

Affected
ISC BIND 9.1.0 through 9.9.7-P1
ISC BIND 9.10.0 through 9.10.2-P2
Appliances and OS builds bundling those BIND versions
Fixed in
BIND 9.9.7-P2
BIND 9.10.2-P3
All later BIND releases
RHEL 6 and 7: RHSA-2015:1513; RHEL 5: RHSA-2015:1514 and RHSA-2015:1515
CVSS
7.5 (v3.1, CISA-ADP)
EPSS
99.4% (percentile 99.9)
CISA KEV
Yes, listed as known exploited
Exploitation
Exploited in the wild
Severity
High

What to do

  1. Find every named instance, including inside appliances, and record its version with named -v.
  2. Upgrade anything older than 9.9.7-P2 or 9.10.2-P3 to a supported BIND release or your vendor's fixed package or firmware, then restart named.
  3. If an appliance cannot be updated, keep untrusted networks from reaching its DNS port; ISC says BIND's own ACLs do not prevent the crash.
  4. Replace or retire devices that still ship 2015-era BIND; they are missing a decade of other DNS fixes too.

How to check if you are affected or compromised

  • Search logs for named exiting on a REQUIRE assertion failure, followed by unexplained restarts.
  • With query logging on (rndc querylog on), look for TKEY queries, which are rare in normal traffic.
  • If an old BIND host was exposed, review it against the other CVEs in CISA advisory AA26-281A, since the same actors pursued initial access and data theft.

What happened#

On July 28, 2015, ISC disclosed CVE-2015-5477 in BIND, the widely deployed open-source DNS server. Its named daemon mishandled TKEY queries. A single crafted packet could trip a REQUIRE assertion, and named would exit. ISC said both recursive and authoritative servers were vulnerable. It also said that "exposure is not prevented by either ACLs or configuration options limiting or denying service", and listed no workarounds. Jonathan Foote found the bug. Proof-of-concept code was public within days. On August 2, 2015, Sucuri wrote "We can confirm that the attacks have begun," based on customers whose DNS servers had crashed.

On October 8, 2026, more than eleven years later, CISA added the CVE to the KEV catalog, with an October 11 deadline for federal agencies. The reason is clearer than for most old KEV entries. The addition came the same day as joint advisory AA26-281A, co-sealed by US, UK, Australian, Canadian, Japanese, New Zealand and Spanish agencies. The advisory describes Chinese government-linked actors who combine automated scanning with hands-on intrusion to steal data. Its table of "successfully exploited" CVEs lists CVE-2015-5477 as a denial-of-service bug, alongside old ProFTPD, Struts, Bash and Pulse Secure flaws. It also notes that the actors scan port 53 (DNS). CISA's announcement says the China-based firm Integrity Technology Group enabled the activity, which it calls consistent with Flax Typhoon, and The Hacker News covered it the same way. The advisory does not say how or against whom the BIND crash was used.

Who is affected#

All BIND 9 versions from 9.1.0 through 9.9.7-P1 and 9.10.2-P2 are affected. ISC fixed them in 9.9.7-P2 and 9.10.2-P3, and every later release includes the fix. Red Hat rated it Important and shipped RHSA-2015:1513 for RHEL 6 and 7 the next day. Other distributions followed. The CVE record also links to advisories from Juniper, Apple, HPE and NetApp, a reminder that BIND ships inside appliances and operating systems, not only on DNS servers you built yourself. NVD carries CISA's CVSS 3.1 score of 7.5, with no confidentiality or integrity impact. This is an availability bug only.

Do you really need to act?#

Most teams don't. If your BIND came from a distribution that has been updated at any point since mid-2015, or from ISC in the last decade, you are fixed. The same goes for teams that use Unbound, PowerDNS, dnsmasq or a managed DNS service. The concern is the stragglers: never-updated CentOS 5 or 6 boxes, ISP and campus resolvers nobody touches, and firewalls or storage appliances with frozen firmware. For those, the bug is trivial to trigger and needs no authentication. Losing DNS takes everything that depends on it down too, so if such a server is internet-facing, treat it as urgent. AA26-281A shows state-linked actors scanning for DNS services and successfully exploiting old bugs like this one.

What to do now#

  1. Inventory. Run named -v on servers, and check rpm -q bind or dpkg -l bind9. For appliances, check the vendor's release notes for the bundled BIND version.
  2. Upgrade anything older than 9.9.7-P2 or 9.10.2-P3 to a currently supported BIND release or your vendor's fixed package or firmware, then systemctl restart named.
  3. If an appliance cannot be updated, restrict who can reach its DNS port at the network edge. ISC says BIND's own ACLs do not stop this bug.
  4. Retire devices that still ship 2015-era BIND. They are missing many later DNS security fixes as well.

How to tell if you were hit#

Successful exploitation looks like an outage. Look for named exiting on a REQUIRE assertion failure in syslog, followed by restarts or a dead resolver. Sucuri recommends enabling query logging with rndc querylog on and searching for TKEY queries, for example with grep -i tkey on your query log. Such queries are uncommon in normal traffic, so any hit deserves a look. A crash by itself does not mean the server was compromised. But if an exposed host was running BIND this old, check it and its neighbors against the rest of the AA26-281A indicators and CVE list, since those actors were after initial access and data.

Timeline#

  • — ISC sends advance notification to customers.
  • — Public disclosure, with fixed BIND 9.9.7-P2 and 9.10.2-P3.
  • — Red Hat ships RHSA-2015:1513 for RHEL 6 and 7.
  • — Sucuri reports attacks in the wild.
  • — Joint advisory AA26-281A lists the CVE as exploited, and CISA adds it to KEV.
  • — Federal remediation deadline.

Vulnerability records

  • CVE-2015-5477 · KEV 2026-10-08 · named in ISC BIND 9.x before 9.9.7-P2 and 9.10.x before 9.10.2-P3 allows remote attackers to cause a denial of service (REQUIRE assertion failure and daemon…

Sources

Original sources first: vendor and project advisories, CVE and government records, the discoverers’ write-ups. Every claim above links to one of these. See how the Security Desk works.

Original and primary sources

  1. ISC — CVE-2015-5477: An error in handling TKEY queries can cause named to exit with a REQUIRE assertion failure kb.isc.org
  2. CVE record — CVE-2015-5477 cve.org
  3. NVD — CVE-2015-5477 nvd.nist.gov
  4. CISA — Known Exploited Vulnerabilities: CVE-2015-5477 cisa.gov
  5. CISA et al. — AA26-281A: Chinese Government-linked Cyber Threat Actors Combine Automated and Hands-on Hacking Tools to Steal Sensitive Data cisa.gov
  6. CISA — CISA, FBI, NSA and International Partners Warn of China-based Cybersecurity Company Enabling Threat Actors cisa.gov
  7. Red Hat — CVE-2015-5477 access.redhat.com
  8. Red Hat — RHSA-2015:1513 bind security update access.redhat.com
  9. Sucuri — BIND9 Denial of Service Exploit in the Wild (Aug 2, 2015) blog.sucuri.net

Coverage and analysis

  1. The Hacker News — Flax Typhoon Exploits Five Flaws as CISA Updates KEV thehackernews.com