BIND 9 Patch behebt 14 DNS-Server-Schwachstellen, darunter ein DoH-Absturz

Das Internet Systems Consortium (ISC), die Organisation, die BIND 9 wartet, hat BIND 9.20.29 und 9.21.26 veröffentlicht, um vierzehn Sicherheitslücken in der Open-Source-DNS-Server-Software zu beheben, alle am 16. September bekannt gegeben. Eine davon betrifft jeden BIND 9-Server, der DNS-over-HTTPS (DoH) beantwortet, eine Methode, DNS-Abfragen – das System, das einen Domainnamen in die Adresse eines Servers umwandelt – in normalen verschlüsselten Webverkehr einzubetten. ISC erklärt in seinen Advisories, dass ein Absender ohne jegliche Anmeldeinformationen den Serverprozess named mit einer einzigen Anfrage zum Absturz bringen kann, die eine ungültige SIG(0)-Signatur trägt, sofern der Absender die Verbindung schließt, bevor named die Überprüfung dieser Signatur abgeschlossen hat. ISC fügt hinzu, dass keine der vierzehn Schwachstellen ausgenutzt wird, soweit bekannt.

Welches Update was behebt, hängt davon ab, welcher Zweig läuft. BIND 9.20.29 im aktuellen stabilen Zweig behebt alle vierzehn. BIND 9.21.26 im Entwicklungszweig behebt dreizehn, da CVE-2026-19662 den 9.21-Zweig nicht betrifft. Die Supported Preview Edition für Support-Kunden, 9.20.29-S1, behebt alle vierzehn und entspricht den in ISCs Advisories aufgeführten -S1-Bereichen. ISC listet keine Workarounds für eine der vierzehn auf, sodass das Anwenden des Updates die einzige angebotene Abhilfe ist.

Ältere Installationen sind in einer schwierigeren Lage. Zwölf der vierzehn betreffen den 9.18-Zweig bis einschließlich 9.18.50, seiner letzten Version. ISC hat den Support für 9.18 Ende Juni eingestellt und listet keine 9.18-Version, die sie behebt. Im Mai erklärte ISC, dass 9.18-Nutzer so schnell wie möglich auf 9.20 umsteigen sollten, und seine Schwachstellenmatrix besagt, dass bei End-of-Life-Versionen davon auszugehen ist, dass sie für neue CVEs anfällig sind – die Standardkennungen für öffentlich katalogisierte Sicherheitslücken. Betriebssystempakete sind eine separate Angelegenheit: Debian 12 liefert ein Paket auf Basis von 9.18.49, und sein Security-Tracker hatte bis 06:20 UTC am 17. September keine der vierzehn aufgeführt.

Zwei der vierzehn können allein durch eine Anfrage ausgelöst werden, ohne dass der Angreifer einen eigenen DNS-Server betreibt, und beide betreffen nur die Zweige 9.20 und 9.21. Der DoH-Absturz ist CVE-2026-77692. Die zweite, CVE-2026-76163, ermöglicht es einer Abfrage vom Typ TKEY – einem Record-Typ, den Nameserver zur Aushandlung von Schlüsseln untereinander verwenden –, named zum Absturz zu bringen, wenn die Konfigurationsdatei des Servers, named.conf, keinen globalen Optionsblock enthält.

Für die meisten anderen benötigt der Angreifer einen rekursiven Resolver – eine Art Server, der Namen im Auftrag von Clients auflöst –, der präparierte Daten von einem vom Angreifer kontrollierten Server empfängt. Eine einzelne präparierte Antwort kann einen Resolver mit Standardkonfiguration zum Absturz bringen (CVE-2026-19667, eine negative Antwort von genau 65.536 Bytes, gesendet von einem vom Angreifer betriebenen Server), einen Resolver, der dns64 mit break-dnssec yes verwendet (CVE-2026-19666, bei dem die fehlerhafte Antwort aus dem Cache geliefert wird), oder einen validierenden Resolver – einen, der die kryptografischen Signaturen an DNS-Daten prüft –, der eine Wildcard-Antwort erhält, die sowohl NSEC- als auch NSEC3-Beweise unter demselben Namen trägt (CVE-2026-80274, die auch einen SERVFAIL oder einen falschen Verneinungsdatensatz erzeugen kann). Eine vierte, CVE-2026-19662, erfordert eine bestimmte Reihenfolge und Zeitpunkt von Antworten aus einer vom Angreifer betriebenen signierten Zone und betrifft 9.21 nicht.

Vier weitere der vierzehn verbrauchen CPU oder Speicher eines Resolvers, anstatt ihn zum Absturz zu bringen. Zwei davon wirken über gecachte SVCB- oder HTTPS-Alias-Records: Bei CVE-2026-81563 wächst der Cache über sein Limit hinaus, bis die Auflösung fehlschlägt, nachdem ein Resolver wiederholt einem SVCB- oder HTTPS-Alias mit mehr als dreizehn Ziel-Records gefolgt ist; bei CVE-2026-81736 kann ein gecachter Alias-Baum den Prozessor erschöpfen, wenn Clients Rekursion erlaubt ist und der Angreifer eine Zone betreibt. CVE-2026-19668 erschöpft die CPU eines validierenden Resolvers durch eine Zone mit vielen Key-Tags und ohne gültige Übereinstimmung; ISC merkt an, dass Standard-Record-Limits die Exposition verringern. CVE-2026-75029 treibt die Speichernutzung über konfigurierte Limits, wenn eine Antwort denselben SOA-, CNAME- oder DNAME-Record viele Male wiederholt. ISC bewertet sieben der vierzehn als High, alle mit 7,5 auf CVSS 3.1 – einer Standardschweregradskala, bei der 10 das Schlimmste ist: die oben beschriebenen Abstürze außer CVE-2026-19662 sowie die beiden SVCB- und HTTPS-Schwachstellen. Die anderen sieben sind Medium, von 5,3 bis 6,5.

Die verbleibenden vier Schwachstellen betreffen die Integrität von DNS-Daten – was ein Server herausgibt oder was ein Resolver akzeptiert –, nicht Abstürze oder Erschöpfung. ISC bewertet alle vier als Medium, und jede ist mit Bedingungen verbunden, wo der Angreifer sitzt oder was er bereits kontrolliert.

Zwei davon ermöglichen es einem validierenden Resolver, den falschen DNSSEC-Beweis zu akzeptieren. Bei CVE-2026-19941 kann ein signierter NSEC-Record aus einer nicht zugehörigen Zone als Beweis dafür durchgehen, dass kein Wildcard existiert. Ein Angreifer auf dem Netzwerkpfad oder ein bösartiger Forwarder, der eine signierte Zone kontrolliert, könnte damit erreichen, dass eine gefälschte NXDOMAIN-Antwort für einen Namen akzeptiert wird, der eigentlich über ein Wildcard aufgelöst werden sollte, und die gefälschte Antwort würde die DNSSEC-Validierung bestehen. Bei CVE-2026-77119 kann ein signierter NSEC3-Record aus einer nicht zugehörigen Schwesterzone als Beweis dafür durchgehen, dass eine Delegation unsigniert ist, und ein Angreifer, der Antworten auf die Abfragen des Resolvers einspeisen kann, könnte dann eine gefälschte unsignierte Antwort für Namen unterhalb dieser Delegation akzeptieren lassen. ISC beschreibt beide Ergebnisse als Cache-Poisoning, also das Behalten und Wiederverwenden falscher Daten durch einen Resolver.

CVE-2026-19033 betrifft einen Sekundärserver, der eine Zone von DNS-Records von einem Primärserver kopiert und nur Transfers akzeptiert, die mit einem TSIG-Schlüssel signiert sind – einem gemeinsamen Geheimnis zur Authentifizierung solcher Transfers. Während eines mehrteiligen inkrementellen Transfers (IXFR) über TCP konnte named beginnen, die neuen Zonendaten auszuliefern, bevor die letzte Nachricht mit der Signatur eintraf, und es machte kein Rollback, wenn diese Signatur nie kam. Eine Partei, die einen solchen Transfer liefern kann, könnte nicht autorisierte Zoneninhalte ausliefern lassen, ohne den Schlüssel zu besitzen. Die Behebung erfordert ein TSIG in jeder Nachricht eines eingehenden Transfers, und ISC sagt, dass moderne Nameserver bereits jede Nachricht signieren, sodass keine Änderung in der Praxis erwartet wird.

CVE-2026-78301 erfordert mehr Zugriff als die anderen: ein Angreifer, der eine fehlerhafte Zone auf einen autoritativen Server laden kann, beispielsweise durch einen Zonentransfer. Eine Zone, die einen NS- oder DNAME-Knoten oberhalb ihres eigenen Ursprungs enthält, wird dann als Zonenschnitt behandelt, sodass Abfragen für Namen innerhalb der Zone eine Out-of-Zone-Delegation zurückgeben anstelle der eigenen Daten der Zone. Wenn der Server auch rekursiert, kann er dieser Delegation folgen und vom Angreifer gelieferte Records für Namen außerhalb der Zone cachen, und der Effekt hält an, solange die fehlerhafte Zone geladen bleibt.

Jedes von ISCs vierzehn Advisories, veröffentlicht am 16. September, besagt, dass der Organisation keine aktiven Exploits bekannt sind. Keine der vierzehn erscheint im Known Exploited Vulnerabilities-Katalog von CISA in der am selben Tag veröffentlichten Version. CISA ist die United States Cybersecurity and Infrastructure Security Agency. Tests, die die Schwachstellen reproduzieren, sind jedoch öffentlich. ISC erklärte im Mai, dass es nun Reproduktionstests veröffentlicht, wenn es eine Schwachstelle publiziert, und der Quellbaum von 9.20.29 fügt Systemtests für mindestens sechs der vierzehn hinzu, darunter einen, der eine ungültige SIG(0)-Anfrage über DoH sendet, die Verbindung schließt und prüft, dass named überlebt. Dies sind Tests, die die Behebung bestätigen, keine Angriffswerkzeuge, aber sie legen die Auslösebedingungen offen.

Vierzehn ist die größte von ISCs fünf BIND-Sicherheitsveröffentlichungen in diesem Jahr, nach einer Schwachstelle im Januar, vier im März, sechs im Mai und neun im Juli. ISC warnte im Mai, dass „Nutzer in jeder monatlichen BIND-Wartungsversion Sicherheitsfixes erwarten sollten“ für den Rest von 2026 – eine Änderung, die laut ISC durch eine Flut von Schwachstellenberichten ausgelöst wurde, die von großen Sprachmodellen generiert wurden, sowohl von Forschern als auch von Angreifern. Die Fixes erscheinen in 9.20.29 statt 9.20.28, weil ISC 9.20.28 vor der Veröffentlichung zurückzog, nachdem Vortests eine Regression festgestellt hatten.

Vier der vierzehn wurden in ISCs eigenen Tests gefunden. Die übrigen wurden gemeldet von Vitaly Simonovich (CVE-2026-77692), Rintaro Kawasugi (CVE-2026-19666 und CVE-2026-19667), Samy Medjahed, auch bekannt als Ap4sh (CVE-2026-19662 und CVE-2026-81563), Henrique Pereira (CVE-2026-78301 und CVE-2026-81736), Owais Lone, auch bekannt als thesecguy (CVE-2026-76163), einem Forscher, der als hythyt genannt wird (CVE-2026-80274), sowie Zuyao Xu und Xiang Li von der Nankai-Universität (CVE-2026-19668).

Für Website-Betreiber und IT-Teams ist die praktische Lesart einfach: Dies ist serverseitige Software, nicht etwas, das ein Besucher oder ein Content-Management-System von außen auslöst. Wenn Ihre Organisation eigene Nameserver betreibt, ist das Update die ganze Geschichte, da ISC keinen Workaround veröffentlicht hat. Wenn Ihr Hosting- oder DNS-Dienst für Sie verwaltet wird, lohnt sich die Frage, ob dieser Anbieter bereits auf 9.20.29 oder 9.21.26 umgestellt hat und was er mit Servern macht, die noch auf dem nicht unterstützten 9.18-Zweig laufen, von dem ISC sagt, dass er als anfällig für neue Schwachstellen gelten sollte. Ein Absturz eines Resolvers ist für sich genommen kein Datendiebstahl, aber er kann einen Domainnamen für alle offline nehmen, die ihn erreichen wollen, und die vier Integritätsschwachstellen zeigen, dass falsche Antworten im Cache eines Resolvers die Art von Problem sind, die viel schwerer zu bemerken ist als ein Ausfall. Leser, die ihre eigene Namensauflösungsschicht lieber nicht selbst betreiben und patchen möchten, können verwaltete Optionen in Betracht ziehen: AEU DNS ist ein privater, sicherer DNS-Dienst – eine Möglichkeit, den Betrieb von Abfragen an einen Anbieter zu übergeben, statt ihn auf eigenen Servern zu behalten. Was in jedem Fall zählt, ist zu wissen, wer für den Patch verantwortlich ist, und eine Antwort zu haben, die man überprüfen kann.