BIND 9.20.30 schließt vier Lücken, eine erlaubt potenziell Codeausführung
ISC hat am 21. Oktober BIND 9.20.30 und 9.21.27 veröffentlicht. Die Updates beheben CVE-2026-94300 (CVSS 8.1, potenzielle Codeausführung über GSS-TSIG-Replay) sowie drei Absturz- und Ressourcenlücken. Workarounds gibt es nicht, aktive Angriffe sind nicht bekannt.

Das Internet Systems Consortium (ISC) hat am 21. Oktober 2026 die BIND-Versionen 9.20.30 und 9.21.27 veröffentlicht und damit vier Sicherheitslücken im Nameserver geschlossen. Die schwerste, CVE-2026-94300, kann über wiederholte GSS-TSIG-signierte UDP-Nachrichten Speicher in named beschädigen und potenziell Codeausführung aus der Ferne ermöglichen. Die drei übrigen Lücken führen zu Abstürzen oder Ressourcenerschöpfung und damit zu einem Ausfall des DNS-Dienstes.
Betroffen sind alle BIND-Server ab 9.11.0 beziehungsweise 9.16.0 bis einschließlich 9.20.29, also auch der Zweig 9.18, für den ISC keine Korrektur mehr liefert. Nicht betroffen sind Umgebungen mit anderen DNS-Servern wie Unbound, Knot oder Windows DNS. Workarounds nennt ISC für keine der vier Lücken, aktive Angriffe sind bisher nicht bekannt. Admins sollten das Update daher zeitnah im nächsten kurzfristigen Wartungsfenster einplanen, bei öffentlich erreichbaren Resolvern und GSS-TSIG-Nutzung möglichst sofort. Zur Einordnung früherer DNS-Lücken eignet sich unser Bericht über die DNSSEC-Lücken in Unbound und BIND 9 vom September.
Was ist passiert?
ISC hat die Lücken am 14. Oktober vorab an Supportkunden gemeldet und am 21. Oktober um 13:03 UTC öffentlich gemacht. Die vier Advisories im Überblick:
- CVE-2026-94300 (CVSS 8.1, hoch): Ein Angreifer, der eine GSS-TSIG-signierte UDP-Nachricht mitschneidet, kann sie erneut senden, solange der ausgehandelte TSIG-Schlüssel gültig ist. Zusammen mit präparierten Anfragen an eine selbst kontrollierte Zone kann das zu Speicherkorruption und potenziell zu Codeausführung führen. Gefunden in internen Tests und unabhängig von Dave Aitel (OpenAI) gemeldet.
- CVE-2026-19630 (CVSS 7.5, hoch): Ein BIND-Resolver verarbeitet bestimmte Strukturen in eingehenden DNS-Nachrichten ohne Obergrenze. Eine Nachricht mit sehr vielen solchen Strukturen treibt CPU-Last und Speicherverbrauch in die Höhe.
- CVE-2026-96888 (CVSS 7.5, hoch): Ein Resolver mit einer „redirect“-Zone und „qname-minimization strict“ kann beim Verarbeiten der Umleitung mit einem Assertion-Fehler abbrechen.
- CVE-2026-97313 (CVSS 7.5, hoch): Ein rekursiver Server mit mindestens zwei RPZ-Zonen, eine mit „recursive-only yes“ und eine mit „recursive-only no“, kann nach einer rekursiven und einer folgenden nicht rekursiven Anfrage abstürzen.
Wer ist betroffen?
Laut ISC sind BIND 9.11.0 bis 9.18.50, 9.20.0 bis 9.20.29 und 9.21.0 bis 9.21.26 von CVE-2026-94300 und CVE-2026-19630 betroffen, bei CVE-2026-96888 und CVE-2026-97313 beginnt der Bereich mit 9.16.0. Dazu kommen die Supported Preview Editions bis 9.20.29-S1. Korrigiert ist das Problem in 9.20.30, 9.21.27 und 9.20.30-S1. Der Zweig 9.18 hat laut ISC-Downloadseite sein Supportende erreicht und erhält keinen Fix.
Die DoS-Lücken greifen nur bei bestimmten Rollen und Konfigurationen: CVE-2026-19630 bei Resolvern, CVE-2026-96888 nur mit Redirect-Zone plus strikter QNAME-Minimierung, CVE-2026-97313 nur mit zwei RPZ-Zonen unterschiedlicher recursive-only-Einstellung. Die Codeausführungslücke setzt GSS-TSIG voraus, das vor allem bei Kerberos-gesicherten dynamischen Updates in Active-Directory-nahen Umgebungen zum Einsatz kommt.
Bei Distributionen ist der Stand unterschiedlich: Debian liefert für Trixie über DSA-6576-1 das Paket 1:9.20.30-1~deb13u1 aus. Bookworm mit BIND 9.18.49 führt der Debian-Security-Tracker zum Prüfzeitpunkt weiterhin als verwundbar.
Wie kritisch ist das?
Hoch, aber nicht akut im Sinne laufender Angriffe. Alle vier Lücken sind aus der Ferne ausnutzbar, Exploits sind laut ISC nicht bekannt. CVE-2026-94300 hat eine hohe Angriffskomplexität, weil der Angreifer signierten Verkehr mitschneiden muss. Die DoS-Lücken sind dagegen einfacher auszunutzen und können einen Resolver zuverlässig lahmlegen.
Was sollten Admins jetzt tun?
- Inventar prüfen: Auf jedem DNS-Server mit
named -vdie Version ermitteln und Distributionspakete mit dem Security-Tracker abgleichen. - Auf BIND 9.20.30 oder das korrigierte Distributionspaket aktualisieren und named neu starten.
- Systeme auf 9.18 oder älter planbar auf 9.20 migrieren, da ISC dort keine Korrektur liefert.
- Konfiguration auf GSS-TSIG, Redirect-Zonen mit „qname-minimization strict“ und gemischte RPZ-Einstellungen prüfen, um Prioritäten zu setzen.
- Rekursion nur für eigene Netze erlauben und Resolver nicht offen ins Internet stellen.
- Abstürze und Neustarts von named im Monitoring sichtbar machen.
Einordnung für Unternehmen
BIND läuft häufig als interner Resolver oder autoritativer Server und wird bei Updates gern vergessen, weil der Dienst unauffällig läuft. Fällt der Resolver aus, stehen Mail, Webzugriffe und Anmeldungen still. Besonders kritisch ist die Lage für Betreiber, die noch Debian 12 oder andere Systeme mit BIND 9.18 einsetzen: Hier fehlt bisher ein Paketupdate, und ein Upstream-Fix ist nicht zu erwarten.
Passende Anleitungen auf S-EDV
- Automatische Sicherheitsupdates mit unattended-upgrades: Paketfixes wie DSA-6576-1 zeitnah einspielen.
- Linux-Server mit ufw und fail2ban absichern: DNS-Ports nur für berechtigte Netze freigeben.


