On October 8, 2026, CISA added CVE-2015-5477 to the Known Exploited Vulnerabilities catalog with a federal remediation due date of October 11, 2026. The vulnerability is an aged ISC BIND defect: an error handling TKEY queries can cause named to exit with a REQUIRE assertion failure, producing a remote denial of service. ISC's historical advisory (AA-01272) is blunt — both recursive and authoritative servers are vulnerable, ACLs do not save you because the bad path runs early in packet handling, and there is no reliable configuration workaround. Patching is the fix. October's KEV wave also pulled in other decade-old infrastructure bugs (ProFTPD, Struts). That pattern matters for DevOps leads: forgotten DNS appliances and "temporary" BIND containers in side VPCs are exactly where aged CVEs still live. If your SaaS resolves customer custom domains, runs split-horizon DNS, or ships a virtual appliance that embeds BIND, this listing is yours even if Cloudflare sits in front of the marketing site.
Affected trains — verify, do not assume "we are on 9.18"
ISC documented affected versions spanning BIND 9.1.0 through 9.9.7-P1 and 9.10.0 through 9.10.2-P2, with patched builds historically at 9.9.7-P2 and 9.10.2-P3 on those trains. Modern supported BIND majors are far past those lines — but inventory still finds 9.9/9.10 packages inside vendor images, old Ubuntu LTS AMIs pinned forever, and network appliances that never got a firmware bump. CISA's KEV row names the product; it does not replace reading your exact named -v output against vendor guidance. Also check recursive resolvers used by application clusters, not only the public authoritative servers. A DoS against internal DNS looks like a random regional outage: pods fail readiness, TLS bootstraps hang, and on-call blames Kubernetes while named has already exited.
Remediation order that fits a SaaS on-call rotation
1. Inventory every BIND. Search AMIs, Helm charts, appliance firmware notes, and customer-managed connectors. Parse package versions in golden images, not tribal memory. 2. Upgrade to a currently supported BIND release (or replace with a managed DNS service if BIND is accidental legacy). Do not "pin forever" on a 2015 patch train if your OS vendor still ships updates on a supported major. 3. Recursion exposure. Open recursive resolvers remain an internet hazard for many reasons beyond this CVE. If a box must recurse, restrict clients; if it is authoritative-only, disable recursion explicitly and prove it with config tests. 4. Hunt and evidence. Review logs for unexpected named exits, REQUIRE assertion failures, and TKEY query spikes around the KEV addition date. Preserve logs before immutable infrastructure rotates them away. 5. Customer appliances. If you ship a VM that includes BIND for local name services, publish an advisory and a minimum version. Your KEV clock includes their installs.
BIND KEV checklist (CVE-2015-5477 / due 2026-10-11)
[ ] named -v on every resolver & authoritative instance
[ ] Map versions to ISC/vendor fixed releases; schedule upgrades
[ ] Confirm recursion ACLs / authoritative-only posture
[ ] Alert on named process exits & core dumps
[ ] Review TKEY / anomalous query logs since KEV add date
[ ] Update customer appliance release notes if you ship BINDWhy founders should care about "old DNS"
DNS downtime is product downtime with worse messaging. Customers do not hear "TKEY assertion failure"; they hear "your app is down" and "SSO login loops." KEV actors and scanners alike will keep probing aged services. A ten-year-old CVE on a modern catalog is not a history lesson — it is a signal that exploitation remains useful against the long tail. Board-level framing: availability SLOs that ignore DNS owners are fiction. Assign an explicit owner for every BIND process the same way you assign owners for Postgres and Redis.
Founder takeaway
CVE-2015-5477 is an ISC BIND TKEY denial-of-service flaw now on CISA KEV with an October 11, 2026 federal due date. Inventory every named , upgrade to supported fixed releases, lock down recursion, and preserve crash evidence. SaaS platforms that treat DNS as invisible plumbing will discover during the next KEV week that plumbing is the product.
Detection without a new product purchase
Alert when the named process exits, when systemd restarts it more than N times per hour, and when core dumps appear. Pair that with resolver latency SLOs from the application side — DNS failures often present as elevated 5xx and auth timeouts before anyone opens the DNS dashboard. If you use CoreDNS or cloud DNS for Kubernetes and a separate BIND for legacy zones, document both. Split ownership is how BIND skips patch cycles.
Network appliances and firewalls that embed BIND need firmware tracking, not only Linux package tracking. Pull the CVE through your vendor's PSIRT search; CISA listing is the prioritization signal, vendor firmware is the fix vehicle.
Architecture choices after the fire drill
Ask whether you still need self-managed BIND at all. Many SaaS teams can move authoritative zones to a managed DNS provider and keep only minimal internal resolvers on supported images. Shrinking the BIND footprint shrinks the next KEV blast radius.
Record the upgrade in your change calendar with CVE id and prior version. The next questionnaire will ask; the next incident commander will thank you.
Operationally, assign a single owner for this topic inside your company calendar this month. Put the primary-source links in the ticket, schedule the verification steps above, and refuse to close the ticket until evidence (version strings, screenshots, or policy exports) is attached. Teams that "align in Slack" without artifacts rediscover the same gap on the next questionnaire or the next KEV weekend. CodeFlamme's bias is simple: dated owners, primary sources, and reversible changes beat heroic fire drills.
