CVE-2015-5477

What is ISC BIND?

BIND is the reference implementation of the Domain Name System, maintained by the Internet Systems Consortium, and named is its server daemon. It is the most widely deployed DNS server software in the world and ships with most Linux and BSD distributions, as well as inside network appliances from vendors including Juniper. A single BIND instance may be an authoritative server publishing a zone to the internet, a recursive resolver serving an enterprise, or both. Either way it is a single point of failure: when the resolver stops answering, every name lookup on the network behind it fails, and when an authoritative server stops answering, the domains it serves disappear from the internet as caches expire.

Overview

CVE-2015-5477 is a remotely triggerable assertion failure in BIND's handling of TKEY queries. TKEY (RFC 2930) is the DNS record type used to negotiate shared secret keys for transaction authentication. A single malformed TKEY query makes named hit an internal consistency check it cannot satisfy and deliberately abort. The process exits, and DNS service for everything behind it stops until something restarts it.

What made this one unusually bad in 2015 was that none of the usual defences applied. The vulnerable code runs early in packet handling, before the query reaches the stage where configuration is consulted, so ISC stated plainly that exposure is not prevented by ACLs or by configuration options that limit or deny service. allow-query, allow-recursion, and view restrictions do not help. Both recursive and authoritative servers are vulnerable, and the attack needs one UDP packet with a spoofable source address, no handshake, and no knowledge of any zone or key the server holds.

ISC rated it 7.8 and labelled it Critical in its own advisory; NVD scores it 7.5 High with availability-only impact (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H), and other vendors published scores between 5.0 and 7.8. The disagreement is about weighting, not about the facts: confidentiality and integrity are untouched, but availability loss is total and trivially repeatable.

Affected Versions

Every BIND 9 release from 9.1.0 onward was affected, a fourteen-year span. Branches 9.1 through 9.8 were already end of life in 2015 and received no patch from ISC, though some distributions backported the fix into their own packages.

Technical Details

The CWE recorded for this CVE is CWE-19, data processing errors, a deliberately broad category; the concrete defect is a failed precondition check rather than a memory safety bug. BIND's source is written with liberal REQUIRE() assertions that document what must be true on entry to a function. When one of them is false the library treats the state as unrecoverable and terminates the process on purpose, trading availability for the certainty of not operating on corrupt state.

Processing a crafted TKEY query drives the message-parsing code down an error path that leaves a name pointer in a state the next call does not expect. Red Hat documents the resulting log line as an assertion failure in message.c on a name pointer that is NULL, at message.c:2311 in the 9.9.x tree, followed immediately by the death of the named process. The exact line number varies by version. Because the failure is an intentional abort rather than memory corruption, the impact ceiling is denial of service: there is no credible path from this bug to code execution or data disclosure.

Operationally the detection story is clean. An unpatched server that is attacked logs the assertion and stops; a patched server logs nothing at all and keeps running. An attacker can loop the packet to keep the service down through automatic restarts.

Discovery

ISC credits Jonathan Foote with discovering and disclosing the vulnerability, and Red Hat's advisory names him as the original reporter. ISC published AA-01272 with the fixed releases on 2015-07-28, and the disclosure was posted to oss-security the following day. ISC's first revision of the advisory recorded no known active exploits; a later revision was updated to note that a third party had published proof-of-concept code to a public repository.

Exploitation Context

Public exploit code appeared within days of disclosure, and it is trivial: a short script that constructs one DNS packet. Red Hat reported receiving reports of ongoing exploitation during the 2015 window. ISC's own advisory stopped short of confirming attacks in the wild and only acknowledged public proof-of-concept code, so the two primary sources differ in how far they go. CISA's 2026-10-08 KEV addition reflects evidence of exploitation; the catalog names no threat actor and marks the CVE as not known to be used in ransomware campaigns.

There are no reliable exposure counts specific to this bug. DNS version banners are frequently hidden or falsified, and version.bind queries are commonly blocked, so scan-derived counts of vulnerable BIND instances are unreliable in both directions. The realistic risk population is embedded and appliance DNS, forgotten internal resolvers, and systems running end-of-life BIND branches that never received a patch.

Remediation

1. Upgrade to a currently supported BIND release. The 2015 fixes were 9.9.7-P2 and 9.10.2-P3, but both branches are long since end of life; move to a supported 9.18 or later branch rather than targeting the historical patch level.
2. On distribution packages, apply the vendor update for your platform. Red Hat, SUSE, Debian, Ubuntu, Oracle, and Amazon all shipped backported fixes.
3. Inventory embedded BIND. Network appliances, firewalls, load balancers, and Junos devices bundle named; apply the vendor's firmware update rather than assuming the appliance is unaffected.
4. Accept that there is no workaround. ISC explicitly states that ACLs and query-limiting configuration do not prevent exposure, so do not substitute a named.conf change for patching. Blocking TKEY at an upstream firewall or DNS proxy is only partial, since the parsing happens before any policy applies in BIND itself.
5. Reduce reachability where you can. Internal resolvers should not accept queries from the internet, and authoritative servers should be behind anycast or a provider that can absorb a packet flood.
6. Review logs for exploitation. Search named logs for REQUIRE assertion failures in message.c and for unexplained process restarts or crash loops. A patched server produces no log entry when attacked, so absence of recent entries after patching is expected.
7. Federal civilian agencies must remediate by 2026-10-11 under BOD 26-04 and perform the forensic triage the directive requires.