Zwei der vierzehn Schwachstellen lassen sich allein durch eine Anfrage auslösen, ohne dass Angreifer einen eigenen DNS-Server benötigen; beide betreffen ausschließlich die Zweige 9.20 und 9.21. Neben dem DoH-Absturz (CVE-2026-77692) ist das CVE-2026-76163: Eine Anfrage vom Typ TKEY bringt named zum Absturz, wenn die named.conf des Servers keinen globalen options-Block enthält.
Die übrigen Abstürze setzen einen rekursiven Resolver voraus, der manipulierte Daten von einem Server unter Kontrolle des Angreifers erhält. Eine einzelne präparierte Antwort genügt, um einen Resolver in Standardkonfiguration (CVE-2026-19667), einen Resolver mit dns64 und break-dnssec yes (CVE-2026-19666) oder einen validierenden Resolver lahmzulegen, der eine Wildcard-Antwort mit NSEC- und NSEC3-Nachweisen zugleich empfängt (CVE-2026-80274). CVE-2026-19662 erfordert eine bestimmte Reihenfolge und Zeitabfolge der Antworten und betrifft 9.21 nicht.
Vier weitere Lücken verbrauchen CPU oder Speicher des Resolvers, statt ihn abstürzen zu lassen – zwei davon über zwischengespeicherte SVCB/HTTPS-Alias-Einträge (CVE-2026-81563 und CVE-2026-81736). Sieben der vierzehn stuft ISC als hoch mit jeweils 7,5 nach CVSS 3.1 ein: die genannten Abstürze mit Ausnahme von CVE-2026-19662 sowie die beiden SVCB/HTTPS-Fehler. Die übrigen sieben liegen im mittleren Bereich zwischen 5,3 und 6,5.
Vier Schwachstellen betreffen nicht Abstürze, sondern die Integrität der DNS-Daten; alle vier bewertet ISC als mittel. Bei CVE-2026-19941 kann ein signierter NSEC-Eintrag aus einer nicht verwandten Zone als Beweis dafür durchgehen, dass keine Wildcard existiert – ein Angreifer auf dem Übertragungsweg oder ein bösartiger Forwarder, der eine signierte Zone kontrolliert, könnte so eine gefälschte NXDOMAIN-Antwort durch die DNSSEC-Validierung bringen. Bei CVE-2026-77119 kann ein signierter NSEC3-Eintrag aus einer unverwandten Nachbarzone als Nachweis gelten, dass eine Delegation unsigniert sei. ISC beschreibt beide Folgen als Cache Poisoning.
CVE-2026-19033 betrifft Secondary-Server, die Zonen nur über TSIG-signierte Transfers annehmen: Bei einem mehrteiligen inkrementellen Transfer (IXFR) über TCP konnte named die neuen Zonendaten bereits ausliefern, bevor die abschließende signierte Nachricht eintraf, und nahm dies nicht zurück, wenn die Signatur ausblieb. Der Fix verlangt nun ein TSIG auf jeder Nachricht; da moderne Nameserver laut ISC ohnehin jede Nachricht signieren, erwartet das Konsortium keine praktische Änderung. CVE-2026-78301 setzt voraus, dass eine fehlerhafte Zone auf einen autoritativen Server geladen wird, etwa per Zonentransfer.
Reproduktionstests sind öffentlich: ISC hatte im Mai angekündigt, solche Tests künftig mit jeder Veröffentlichung bereitzustellen; der Quellbaum von 9.20.29 enthält Systemtests für mindestens sechs der vierzehn Lücken, darunter einen, der eine ungültige SIG(0)-Anfrage über DoH sendet, die Verbindung schließt und prüft, ob named überlebt.
Mit vierzehn Lücken ist es das umfangreichste der fünf BIND-Sicherheitsreleases dieses Jahres – nach einer Lücke im Januar, vier im März, sechs im Mai und neun im Juli. ISC führt die Entwicklung auf eine Flut von Schwachstellenmeldungen zurück, die mit großen Sprachmodellen erzeugt werden. Version 9.20.28 hatte ISC vor der Veröffentlichung zurückgezogen, nachdem Tests eine Regression offenbart hatten. Vier Lücken fand ISC selbst, gemeldet wurden die übrigen unter anderem von Vitaly Simonovich, Rintaro Kawasugi, Samy Medjahed (Ap4sh), Henrique Pereira, Owais Lone (thesecguy), einem Forscher namens hythyt sowie Zuyao Xu und Xiang Li von der Nankai-Universität.