An 11 Year Old BIND Bug Just Joined CISA Known Exploited Vulnerabilities
CVE-2015-5477 is a BIND denial-of-service vulnerability disclosed in 2015. It was added to CISA’s Known Exploited Vulnerabilities catalog on October 8, 2026, confirming active exploitation this month, eleven years after it was originally patched. Its EPSS score, the probability of exploitation in the near term, sits in the 99.8th percentile. If your organization has any BIND name server running an ancient, unpatched version, and that’s more common than it should be for infrastructure that “just works” and gets left alone for years, it is being actively targeted right now.
Why an 11 year old bug is suddenly “new” news
CISA’s KEV catalog doesn’t track new vulnerabilities, it tracks vulnerabilities with confirmed real-world exploitation, regardless of how old the CVE number is. A vulnerability joining the list in October 2026 means someone, somewhere, is actively using it against real targets right now, not that it was just discovered. For a bug this old, that almost always means attackers are scanning broadly for the specific subset of internet-facing infrastructure that never got patched in over a decade, legacy DNS servers are exactly the kind of “set it up once and forget about it” infrastructure where that happens.
What the vulnerability actually does
An unauthenticated, remote attacker sends a specially malformed TKEY query to a vulnerable BIND named process. The malformed query triggers a REQUIRE assertion failure inside BIND, which causes the daemon to exit immediately. No authentication, no privileges, and no user interaction are required, just network reachability to the DNS service. The result is a denial of service: the name server crashes and stops answering queries until something restarts it.
For an authoritative or recursive DNS server that other systems depend on, that’s not a minor inconvenience. Name resolution failures cascade into application failures, authentication failures (anything depending on SRV/A records to find a domain controller or an identity provider), and general connectivity problems across everything that relies on that server.
Who’s affected
ISC BIND named versions 9.x before 9.9.7-P2, and 9.10.x before 9.10.2-P3. Those fixes shipped in 2015, so any instance still exposed to this is running a build that is well over a decade out of date, which on its own is worth treating as a red flag regardless of this specific CVE, a BIND install that old is very likely missing many other fixes too.
Step 1: find out if you’re running BIND at all, and what version
It’s common for a BIND instance to have been set up by someone no longer at the organization and simply never revisited. Check explicitly rather than assuming you’d already know:
# Check locally on a suspected DNS server
named -v
dpkg -l | grep bind9 # Debian/Ubuntu
rpm -q bind # RHEL/AlmaLinux/Rocky
# Check remotely, against any DNS server you're not sure about
dig @your-dns-server version.bind chaos txtNote that many BIND deployments disable the CHAOS version query specifically to avoid leaking their version to the internet, a result of “connection refused” or no answer from that specific query doesn’t mean BIND isn’t running, just that version disclosure is turned off, which is itself a reasonable default. If you manage the server, check locally instead.
Step 2: patch to a current BIND release
Any currently supported BIND 9 release already includes this fix, it’s been in every release for over a decade. If you find a version older than 9.10.2-P3 (or, realistically, anything from the 9.9/9.10 branch at all at this point), the right move isn’t to find the minimal patch for just this one CVE, it’s to upgrade to your distribution’s current supported BIND package entirely, since a build that old is missing far more than just this fix.
# Debian/Ubuntu
sudo apt update && sudo apt install --only-upgrade bind9
# RHEL/AlmaLinux/Rocky
sudo dnf update bindStep 3: if you can’t patch immediately, restrict network exposure
If this is a recursive resolver not meant to be reachable from the public internet, firewall it down to only the internal networks that genuinely need it, exposure to the whole internet for an internal resolver is a separate, independent problem worth fixing regardless of this CVE. For a genuinely authoritative public-facing server, network restriction isn’t an option, patching isn’t optional, it’s the only real fix.
Quick guide
- Inventory every DNS server you run, including ones that “just work” and haven’t been touched in years.
- Check BIND version locally on each one, don’t rely solely on remote version queries, many are disabled by design.
- Upgrade anything on the 9.9/9.10 branch (or older) to your distribution’s current supported BIND package.
- If you can’t patch an internal resolver immediately, firewall it to only the networks that need it.
FAQ
If this was patched in 2015, why does it matter now?
Because CISA’s KEV listing confirms active, real-world exploitation happening right now, in October 2026, against whatever unpatched instances still exist. The vulnerability’s age doesn’t reduce its danger to a system that never got the fix, it just means attackers have had over a decade to find and target the remaining exposed instances.
Does this affect Windows DNS Server or other non-BIND DNS software?
No, this CVE is specific to ISC BIND’s named codebase. Microsoft DNS Server, dnsmasq, PowerDNS, Knot DNS, and other DNS implementations are unrelated codebases and aren’t affected by this specific flaw.
Is this a remote code execution risk, or just denial of service?
Denial of service only, the malformed query crashes the named process rather than executing attacker-controlled code. That’s still serious for availability, especially for an authoritative server other systems depend on, but it’s a different risk profile than a code execution flaw.
If named crashes, does it restart automatically?
That depends entirely on your service manager configuration, not on the vulnerability itself. A systemd unit without an appropriate Restart= policy will simply stay down until something manually restarts it. Check your own service configuration, don’t assume it recovers on its own.
