ISC BIND TKEY DoS Re-Exploited in 2026: KEV Detection and Remediation Guide

On 2026-10-08, CISA added CVE-2015-5477, an ISC BIND data-processing error in the handling of TKEY DNS queries, to the Known Exploited Vulnerabilities catalog. The identifier is old; the signal is current. CISA KEV inclusion means defenders should treat this as actively exploited or reliably exploitable against reachable infrastructure right now, not as a historical footnote. The impact is denial of service: a remote attacker can send a malformed DNS message containing a TKEY record and cause the vulnerable named process to hit a REQUIRE assertion and exit. For organizations still running end-of-life BIND 9.9 or 9.10 branches, vendor appliances that embedded those branches, or exposed legacy resolvers and authoritative servers, this is an availability risk to DNS itself.

DNS is a dependency for almost everything else: identity, email, web, SaaS egress, VPN enrollment, certificate validation, and incident response tooling. A repeatable remote crash of named is therefore not just a nuisance. It can be used to blind monitoring, interrupt failover, degrade authentication, force clients to secondary resolvers, or create noisy cover for another intrusion. The required posture is simple: remove vulnerable code where possible, reduce exposure where removal is delayed, and instrument for the exact observable behavior: inbound TKEY from unusual peers followed by assertion, crash, restart, or service flapping.

Technical analysis

Affected component: ISC BIND named, specifically vulnerable BIND 9 code paths that parsed TKEY resource records incorrectly. Public vendor fixes for the original issue were released in the 9.9 and 9.10 maintenance lines as 9.9.7-P3 and 9.10.2-P3, while later supported branches such as 9.16, 9.18, and 9.20 are not vulnerable to this specific defect. The present-day problem is the long tail: EOL Linux distributions, frozen images, embedded DNS in appliances, lab servers accidentally exposed, inherited authoritative servers, and containers built from stale base images. Scoring is High for availability in modern CVSS terms, commonly around 7.5 for an unauthenticated network attack with no confidentiality or integrity impact, though older records may show legacy v2 metrics. Treat scanner severity as secondary to CISA KEV status and internet exposure.

The defensive attack-chain view is narrow. The attacker needs network reachability to UDP or TCP 53 on a vulnerable named instance. They do not need valid TSIG credentials. The crafted packet includes a TKEY RR whose processing triggers an assertion failure in named; the daemon terminates rather than returning a normal DNS error. On systemd hosts this looks like named.service entering failed state, followed by RestartSec-driven relaunch if the unit is configured to restart. On some appliances the process supervisor may restart silently, which can hide repeated crashes unless logs are centralized. Repeated probing can produce intermittent resolution failures, zone transfer failures, or cache-servicing gaps even when the service appears up between attempts.

Exploitation status: confirmed current relevance through CISA KEV addition on 2026-10-08. The remediation language in the KEV record points organizations to vendor mitigations and BOD 26-04 risk-based update handling, including evaluation of internet exposure, cloud-service applicability, and discontinuation where mitigations are unavailable. Practically: if an asset answers DNS from untrusted networks and runs an EOL BIND branch, assume it can be found and knocked over.

Detection and response

Do not rely only on vulnerability scanners. A scanner can tell you named is old; it cannot tell you someone is sending TKEY at it this afternoon. Prioritize three telemetry sources: DNS query logs from Zeek, Suricata, Corelight, firewall, or DNS firewall; named logs via Syslog; and service-manager state from systemd or the appliance supervisor. Legitimate TKEY exists in TSIG-signed dynamic update environments, so baseline known update sources such as DHCP failover peers, domain controllers, hidden primaries, and automation before declaring high confidence. Internet-facing authoritative servers should normally see little to no TKEY from arbitrary sources; recursive resolvers should not accept dynamic update traffic from clients at all.

---
title: Unusual External DNS TKEY Query to Exposed BIND
description: Detects inbound DNS queries containing TKEY records from sources that are not approved dynamic-update or TSIG peers. Tune the approved peer list before enabling at high severity.
logsource:
  category: dns
  product: zeek
detection:
  selection:
    qtype_name: TKEY
  filter_approved_peers:
    id.orig_h|cidr:
      - 10.0.0.0/8
      - 172.16.0.0/12
      - 192.168.0.0/16
      - 203.0.113.10/32
  condition: selection and not filter_approved_peers
falsepositives:
  - Legitimate TSIG or dynamic DNS updates from unmanaged but authorized peers
  - DNS research scanners and upstream monitoring
level: high
tags:
  - attack.impact
  - attack.t1498
references:
  - https://www.cisa.gov/known-exploited-vulnerabilities-catalog?search_api_fulltext=CVE-2015-5477
author: Security Arsenal
date: 2026/10/08
---
title: ISC BIND named Assertion Failure or Crash Exit
description: Detects BIND named logging assertion failure, REQUIRE errors, fatal exiting, or crash loops consistent with malformed TKEY denial of service.
logsource:
  product: linux
  service: named
detection:
  selection:
    message|contains:
      - REQUIRE
      - assertion failure
      - exiting due to assertion failure
      - fatal
      - tkey
      - named.service: Failed
      - named.service: Main process exited
  condition: selection
falsepositives:
  - Misconfigured zones or bad TSIG keys can generate named errors, but assertion REQUIRE plus process exit is uncommon
level: critical
tags:
  - attack.impact
  - attack.t1499
references:
  - https://www.cisa.gov/known-exploited-vulnerabilities-catalog?search_api_fulltext=CVE-2015-5477
author: Security Arsenal
date: 2026/10/08

let approved_update_peers = dynamic(['10.0.0.0/8','172.16.0.0/12','192.168.0.0/16','203.0.113.10']);
union isfuzzy=true
(
  CommonSecurityLog
  | where DestinationPort == 53
  | where AdditionalExtensions has 'TKEY' or Message has 'TKEY' or RequestURL has 'TKEY'
  | where not(ipv4_is_in_any_range(SourceIP, approved_update_peers))
  | project TimeGenerated, SourceIP, DestinationIP, DestinationPort, Protocol=ApplicationProtocol, DeviceVendor, DeviceProduct, Message, AdditionalExtensions
),
(
  Syslog
  | where ProcessName =~ 'named' or SyslogMessage has 'named'
  | where SyslogMessage has_any ('REQUIRE','assertion failure','exiting due to assertion failure','tkey','named.service: Failed','Main process exited')
  | project TimeGenerated, HostIP, Computer, ProcessName, SeverityLevel, SyslogMessage
),
(
  DeviceNetworkEvents
  | where LocalPort == 53 and RemoteIPType == 'Public'
  | where InitiatingProcessFileName =~ 'named' or FileName =~ 'named'
  | summarize Connections=count(), UniqueRemoteIPs=dcount(RemoteIP), FirstSeen=min(TimeGenerated), LastSeen=max(TimeGenerated) by DeviceName, LocalIP, RemoteIP
  | where UniqueRemoteIPs > 25 or Connections > 100
)
| order by TimeGenerated desc

-- Scope DNS servers and look for named exposure, recent restarts, configs, and logs.
LET named = SELECT Pid, Ppid, Name, Exe, CommandLine, Username, CreateTime
FROM pslist()
WHERE Name =~ 'named' OR Exe =~ '/named' OR CommandLine =~ 'named'

SELECT named.Pid, named.Name, named.Exe, named.Username, named.CreateTime,
       conn.Status, conn.Laddr.IP AS LocalIP, conn.Laddr.Port AS LocalPort,
       conn.Raddr.IP AS RemoteIP, conn.Raddr.Port AS RemotePort,
       cfg.OSPath AS ConfigPath, cfg.Mtime AS ConfigMtime,
       log.OSPath AS LogPath, log.Mtime AS LogMtime
FROM named
LEFT JOIN netstat() AS conn ON conn.Pid = named.Pid AND conn.Laddr.Port = 53
LEFT JOIN glob(globs=['/etc/named.conf','/etc/bind/named.conf','/etc/bind/named.conf.options','/etc/named/*','/var/named/*']) AS cfg ON TRUE
LEFT JOIN glob(globs=['/var/log/syslog','/var/log/messages','/var/log/named/*','/var/log/bind/*']) AS log ON TRUE
ORDER BY named.CreateTime DESC

#!/usr/bin/env bash
# Verify and reduce CVE-2015-5477 exposure. Default is check-only; use --apply to add rate limiting.
set -euo pipefail
APPLY=0
[ "${1:-}" = '--apply' ] && APPLY=1

echo '[*] BIND version evidence'
if command -v named >/dev/null 2>&1; then named -v; else echo '[!] named not found in PATH'; fi
if command -v named-checkconf >/dev/null 2>&1; then named-checkconf -p 2>/dev/null | grep -E 'allow-(query|recursion|transfer|update)|blackhole|listen-on|pid-file' || true; fi
rpm -qa 2>/dev/null | grep -Ei '^bind|^isc-bind' || dpkg-query -W 2>/dev/null | grep -Ei 'bind9|isc-dhcp' || true

echo '[*] Exposure check'
ss -lntup 2>/dev/null | grep -E ':53[[:space:]]' || true
if systemctl list-unit-files named.service >/dev/null 2>&1; then systemctl --no-pager --full status named.service | sed -n '1,25p' || true; fi
journalctl -u named.service --since '-24 hours' --no-pager 2>/dev/null | grep -Ei 'REQUIRE|assertion|exiting|tkey|failed|Main process exited' | tail -50 || true

echo '[*] EOL branch heuristic - treat any hit as urgent'
VER=$(named -v 2>/dev/null | awk '{print $2}' || true)
case "$VER" in
  9.9.*|9.10.*|9.8.*|9.7.*|9.6.*|9.5.*|9.4.*) echo '[!] Vulnerable or unsupported BIND branch suspected. Upgrade to a supported 9.18/9.20 or vendor backport immediately.' ;;
  *) echo '[+] Version is not in the classic EOL 9.4-9.10 range; still confirm vendor backport and exposure.' ;;
esac

if [ "$APPLY" -eq 1 ]; then
  echo '[*] Applying conservative nftables rate limit for inbound DNS; review before use in anycast or high-QPS authoritative environments'
  nft list table inet dns_guard >/dev/null 2>&1 || nft add table inet dns_guard
  nft list chain inet dns_guard input >/dev/null 2>&1 || nft add chain inet dns_guard input '{ type filter hook input priority -10; policy accept; }'
  nft add rule inet dns_guard input udp dport 53 ct state new limit rate over 200/second burst 100 packets log prefix 'DNS53_UDP_DROP ' drop
  nft add rule inet dns_guard input tcp dport 53 ct state new limit rate over 100/second burst 50 packets log prefix 'DNS53_TCP_DROP ' drop
  echo '[+] nftables dns_guard installed. Persist with your normal nftables.conf workflow.'
else
  echo '[*] Check-only complete. Re-run with --apply to add temporary rate limiting.'
fi

Response workflow: isolate the asset at the network edge rather than simply restarting named. Capture pcaps and full DNS query logs before filtering if safe to do so, preserving source IP, query name, qtype, EDNS options, TCP versus UDP, and timestamp. Check whether the target is authoritative only, recursive only, or mixed-role; mixed-role legacy servers are the highest priority because they often expose recursion and dynamic update accidentally. Confirm whether crashes align with config reloads, zone transfers, DHCP dynamic updates, or external scanning. If the server is downstream of a DNS firewall or load balancer, verify whether the malformed packet reaches named or is normalized upstream. Escalate to incident response if crashes coincide with authentication outages, unexpected secondary DNS use, zone-data changes, or any beaconing during the availability gap.

Remediation and hardening

Patch decisively. For historical fixed branches, the original corrections were 9.9.7-P3 and 9.10.2-P3, but in 2026 the correct target is not to nurse an EOL branch forward one patch level. Move to a supported ISC branch such as 9.18 or 9.20, or install the operating-system vendor backport that explicitly lists CVE-2015-5477 and current BIND fixes. Validate with named -v, package changelogs, and vendor advisory mapping rather than version strings alone, because enterprise Linux often backports fixes without changing the upstream-looking version. Reference points: the CISA KEV entry at https://www.isc.org/download/ and the relevant ISC knowledge-base advisory for the fixed release matrix.

Reduce attack surface while patching. Internet-facing authoritative servers should disable recursion, restrict allow-query to intended zones, deny allow-transfer except to approved secondaries, and set allow-update and allow-update-forwarding to none or explicit TSIG peers. Recursive resolvers must be reachable only from trusted client ranges and should never accept dynamic updates from ordinary clients. Use minimal listen-on and listen-on-v6 statements, blackhole known-abusive ranges only after care, and place DNS behind an anycast or DDoS-aware DNS layer for public authoritative service. Rate limiting helps against volume, but the CVE crash is a packet-quality bug; do not mistake traffic shaping for a fix.

Meet the governance requirement without theater. For each named asset, record owner, role, exposure, version and backport evidence, KEV due-date status under your BOD 26-04-aligned SLA, compensating controls, and decommission date if the platform cannot be patched. If a cloud DNS service or managed resolver can replace the function, migrate rather than rebuild brittle legacy DNS. If mitigations are unavailable for an exposed appliance, CISA's language is blunt: discontinue use of the product for that role. After remediation, keep the detections above for at least one patch cycle and add a synthetic check that alerts when named restarts more than once in five minutes or when TKEY arrives from outside the approved peer set.

Related Resources

Security Arsenal Penetration Testing Services AlertMonitor Platform Book a SOC Assessment vulnerability-management Intel Hub