ISC BIND 9: Speicherbeschädigung in named durch wiederholte GSS-TSIG-Nachrichten

Zusammenfassung

ISC BIND 9 enthält einen Fehler in der GSS-TSIG-Verarbeitung des DNS-Servers named, der zu einer Speicherbeschädigung führt. Ein Angreifer, der eine zuvor signierte UDP-Nachricht abfangen kann, kann diese erneut senden, solange der ausgehandelte TSIG-Schlüssel noch gültig ist. Durch zusätzlich gesendete, manipulierte Anfragen an eine vom Angreifer kontrollierte Zone könnte er möglicherweise Remote Code Execution erreichen, eine funktionierende Ausnutzung ist jedoch nicht bestätigt.

Betroffen

• ISC BIND 9 9.11.0 bis 9.18.50
• ISC BIND 9 9.20.0 bis 9.20.29
• ISC BIND 9 9.21.0 bis 9.21.26
• ISC BIND 9 9.11.3-S1 bis 9.18.50-S1
• ISC BIND 9 9.20.9-S1 bis 9.20.29-S1
• Die Standardkonfiguration ist nicht betroffen; GSS-TSIG muss aktiviert sein.

Behoben in

• BIND 9.20.30
• BIND 9.21.27
• BIND 9.20.30-S1
• Aktualisieren Sie auf die korrigierte Version, die Ihrem aktuellen Zweig am nächsten liegt. Korrigierte Versionen für 9.18 und ältere sind unbekannt; prüfen Sie die Schwachstellenmatrix von ISC.

Umgehung

• ISC nennt keine bekannten Workarounds.
• Red Hat empfiehlt, die GSS-TSIG-Direktiven (tkey-gssapi-keytab, tkey-gssapi-credential) zu entfernen, falls Kerberos-authentifizierte dynamische DNS-Updates nicht benötigt werden, und danach named neu zu starten. Dies unterbricht Kerberos-basierte dynamische Updates wie die AD- oder IdM-Registrierung.
• Beschränken Sie den Netzwerkzugriff auf den DNS-Dienst mit Firewall-Regeln. Diese Massnahmen reduzieren die Exposition, ersetzen aber nicht das Patchen.

Ausnutzung

• ISC ist keine aktive Ausnutzung bekannt.
• CISA-SSVC-Bewertung: Ausnutzung keine, automatisierbar nein, technische Auswirkung total.
• In den geprüften Quellen wurde kein öffentlicher Proof of Concept gefunden.

Unsere Empfehlung

• Prüfen Sie, ob named GSS-TSIG verwendet (suchen Sie in named.conf nach tkey-gssapi-Direktiven).
• Falls GSS-TSIG verwendet wird, patchen Sie zeitnah auf 9.20.30, 9.21.27 oder 9.20.30-S1.
• Falls Sie 9.18 oder älter einsetzen, planen Sie jetzt die Migration auf 9.20.
• Falls GSS-TSIG nicht verwendet wird, ist das Risiko gering, die Version sollte aber im regulären Wartungsfenster eingespielt werden, da sie auch drei DoS-Schwachstellen behebt.
• Beschränken Sie DNS-Server, die aus unsicheren Netzen erreichbar sind, und überwachen Sie Abstürze von named.

Öffentliche Exploits iAngriffscode ist öffentlich verfügbar (PoC auf GitHub, Metasploit oder Exploit-DB).

Links zu fremden Seiten, von uns nicht geprüft – Exploit-Code kann Schadsoftware enthalten. Nur in isolierten Testumgebungen verwenden.

• Proof of Concept auf GitHub (1 Repositories) iAngriffscode ist öffentlich verfügbar (PoC auf GitHub, Metasploit oder Exploit-DB).
  Ibonok/CVE-2026-94300

Quellen der Recherche

• ISC BIND 9.20.30 download page downloads.isc.org
• ISC BIND 9.21.27 download page downloads.isc.org
• ISC advisory CVE-2026-94300 kb.isc.org
• ISC vulnerability matrix kb.isc.org
• BIND 9.20.30 release notes bind9.readthedocs.io
• Red Hat CVE page CVE-2026-94300 access.redhat.com
• Belgian CCB advisory ccb.belgium.be
• Canadian Cyber Centre advisory AV26-1072 www.cyber.gc.ca

Recherchiert und auf Deutsch und Englisch aufbereitet von einer KI (Claude von Anthropic) auf Basis von NVD, CISA, EPSS und den genannten Quellen. Massgebend sind die Angaben des Herstellers. Recherche vom 01.11.2026 18:11.