BIND 9: Vierzehn Lücken geschlossen — eine DoH-Anfrage genügt, um den DNS-Server abzuschießen

Das Internet Systems Consortium (ISC) hat mit BIND 9.20.29 und 9.21.26 vierzehn Sicherheitslücken in seinem DNS-Server geschlossen — der Software, die einen großen Teil der weltweiten Namensauflösung betreibt und auch in vielen Heimnetzen und Homelabs als Resolver läuft. Sieben der Lücken bewertet ISC als hoch. Die unangenehmste: Wer BIND als DNS-over-HTTPS-Server betreibt, kann von jedem Beliebigen mit einer einzigen Anfrage zum Absturz gebracht werden.

Angriffe in freier Wildbahn sind ISC nicht bekannt. Die Tests, mit denen sich die Lücken nachstellen lassen, sind allerdings öffentlich — ISC veröffentlicht sie seit diesem Jahr zusammen mit den Advisories. Wer BIND betreibt, sollte das Update deshalb nicht aufschieben.

Das Wichtigste in Kürze

• 14 Lücken, veröffentlicht am 16. September: sieben Abstürze oder Ressourcen-Erschöpfung mit CVSS 7,5, sieben mittlere zwischen 5,3 und 6,5.
• CVE-2026-77692: Ein DoH-Request mit ungültiger SIG(0)-Signatur, dessen Verbindung vor Abschluss der Prüfung geschlossen wird, lässt named abstürzen. Ohne Anmeldung, ohne eigenen DNS-Server.
• CVE-2026-76163: Eine TKEY-Anfrage crasht Server, deren named.conf keinen globalen options-Block hat.
• Vier Lücken betreffen die Integrität von DNS-Daten, darunter zwei, mit denen ein validierender Resolver gefälschte DNSSEC-Beweise akzeptiert — ISC spricht von Cache Poisoning.
• Fix: 9.20.29 (alle 14) und 9.21.26 (13, eine betrifft 9.21 nicht). Keine Workarounds.
• 9.18 ist seit Juni außer Support und bekommt keinen Fix, obwohl zwölf der Lücken es betreffen. Debian 12 liefert ein 9.18-Paket — dort war am 17. September noch keine der Lücken im Security-Tracker.

Welche Lücken ohne eigenen Server ausnutzbar sind

Der Unterschied zwischen den vierzehn Lücken liegt in der Frage, was ein Angreifer mitbringen muss. Zwei kommen mit einer bloßen Anfrage aus:

• CVE-2026-77692 (DoH): Ein DNS-over-HTTPS-Request, der eine kryptografisch ungültige SIG(0)-Signatur trägt; schließt der Client die Verbindung, bevor named die Prüfung abgeschlossen hat, bricht der Prozess ab. Betroffen sind nur 9.20 und 9.21 — und nur Server, die DoH beantworten.
• CVE-2026-76163 (TKEY): Eine Anfrage vom Typ TKEY löst einen Assertion-Fehler aus, wenn die Konfiguration keinen globalen options-Block enthält. Ebenfalls nur 9.20 und 9.21.

Die übrigen Abstürze und Erschöpfungen setzen voraus, dass der angegriffene Server ein rekursiver Resolver ist, der Antworten von einem Server holt, den der Angreifer kontrolliert — also eine Domain, deren Nameserver dem Angreifer gehören. Das ist eine niedrige Hürde: Eine Domain kostet wenige Euro, und ein Resolver fragt jede Domain an, die ein Client aufruft.

Die vier Integritätslücken

Abstürze sind ärgerlich, aber sichtbar. Gefährlicher sind die vier Lücken, bei denen ein Server falsche Daten liefert oder akzeptiert, ohne dass es jemand merkt:

• Mit CVE-2026-19941 akzeptiert ein validierender Resolver einen signierten NSEC-Record aus einer fremden Zone als Beweis, dass kein Wildcard existiert. Ein Angreifer, der eine signierte Zone kontrolliert und sich als Forwarder oder auf dem Pfad befindet, kann so ein gefälschtes „Domain existiert nicht“ durch die DNSSEC-Prüfung bringen.
• Mit CVE-2026-77119 gilt ein NSEC3-Record einer Nachbarzone als Beweis, dass eine Delegation unsigniert ist — der Resolver akzeptiert danach unsignierte, gefälschte Antworten für Namen darunter.
• CVE-2026-19033 betrifft Secondary-Server, die nur TSIG-signierte Zonentransfers annehmen: Bei einem mehrteiligen inkrementellen Transfer über TCP begann named, die neuen Daten auszuliefern, bevor die abschließende Signatur kam — und nahm sie nicht zurück, wenn sie ausblieb.
• CVE-2026-78301 braucht mehr: eine fehlerhafte Zone mit NS- oder DNAME-Eintrag oberhalb des eigenen Ursprungs, etwa per Zonentransfer eingeschleust. Der Server behandelt sie als Zone-Cut und liefert für Namen in der Zone eine fremde Delegation.

Wer betroffen ist — und wer nicht

BIND läuft bei Providern, Registraren und in Firmennetzen, aber auch auf vielen Heimservern als lokaler Resolver. Wer stattdessen Pi-hole mit dem eingebauten FTL-Resolver, Unbound, dnsmasq oder AdGuard Home nutzt, ist von dieser Meldung nicht betroffen. Wer BIND als Resolver hinter Pi-hole oder als autoritativen Server für eigene Domains betreibt, sollte die Version prüfen:

named -v

Zwei Punkte für Distributionen: Debian 12 liefert BIND auf Basis von 9.18.49, einer Reihe, die ISC seit Ende Juni nicht mehr pflegt. Debian muss die Fixes selbst rückportieren; am 17. September war noch nichts im Security-Tracker. Wer die Paketversion nutzt, wartet auf das Debian-Update oder wechselt auf 9.20 aus den Backports oder aus ISCs eigenen Paketquellen. Und 9.20.28 gibt es nicht: ISC hat die Version vor der Freigabe wegen einer Regression zurückgezogen, deshalb springt die Nummer auf 9.20.29.

Einordnung

Vierzehn Lücken auf einmal klingen dramatisch, sind aber das Ergebnis eines koordinierten Veröffentlichungstermins: ISC sammelt gemeldete Fehler und schließt sie gebündelt. Bemerkenswert ist der DoH-Absturz, weil DNS-over-HTTPS eine vergleichsweise neue Funktion in BIND ist und Angriffsfläche mitbringt, die klassische Resolver nicht hatten. Wer DoH auf BIND nur eingeschaltet hat, weil es geht, kann es bis zum Update abschalten — der Rest der Lücken braucht ohnehin das Update. Für Homelab-Betreiber ist das eine gute Gelegenheit, den Resolver auf 9.20 zu heben, wenn er noch auf 9.18 steht: Die Reihe ist tot, und die nächste Sammelmeldung kommt.

Häufige Fragen

Bin ich mit Pi-hole, Unbound oder dnsmasq betroffen?

Nein. Diese Lücken betreffen ausschließlich BIND 9 von ISC. Pi-hole nutzt einen eigenen Resolver auf dnsmasq-Basis.

Muss ich DoH abschalten?

Nur bis zum Update, und nur wenn BIND selbst als DoH-Server dient. Nach dem Update auf 9.20.29 oder 9.21.26 ist die Lücke geschlossen.

Ich habe BIND 9.18 aus Debian. Was tun?

Auf das Debian-Sicherheitsupdate warten oder auf 9.20 wechseln. ISC selbst liefert für 9.18 keinen Fix mehr und empfiehlt seit Mai den Umstieg.

Wurden die Lücken schon angegriffen?

ISC ist keine Ausnutzung bekannt. Die Reproduktionstests sind aber öffentlich, was die Hürde für Angreifer senkt.

Quellen: ISC Security Advisories und Release Notes zu BIND 9.20.29 und 9.21.26 (16.09.2026), Berichterstattung von The Hacker News (17.09.2026) und LinuxCompatible. Abgerufen am 17.09.2026.