Die kurze Antwort
Ein ungepatchter BIND-Resolver lässt sich mit einer einzigen Anfrage zum Absturz bringen. Am 16. September 2026 legte ISC 14 Schwachstellen in BIND 9 offen — sieben hoch (CVSS 7.5), sieben mittel — und lieferte die Fixes in BIND 9.20.29 und 9.21.26. Am auffälligsten ist CVE-2026-77692: Ein nicht authentifizierter Angreifer bringt den named-Prozess zum Absturz, indem er eine fehlerhafte DNS-over-HTTPS-Anfrage mit einem kryptografisch ungültigen SIG(0)-Datensatz sendet und die Verbindung früh schließt. Weitere Lücken ermöglichen Speichererschöpfung, Cache-Poisoning und das Einschleusen beliebiger Daten in DNS-Zonen. ISC ist keine Ausnutzung in freier Wildbahn bekannt; die Abhilfe ist ein sofortiges Update.
Für Teams im DACH-Raum ist der Punkt nicht eine einzelne CVE — sondern dass DNS die Abhängigkeit unter jeder anderen Abhängigkeit ist. Steht die Namensauflösung still, steht alles still, was einen Hostnamen auflöst, vom API-Gateway bis zum Callback des Zahlungsdienstleisters. Deshalb gehört DNS in denselben Patch-Rhythmus und dieselbe Resilienz-Planung wie der Rest Ihrer Cloud- und DevOps-Plattform — und nicht in eine Schublade mit der Aufschrift „einmal einrichten und vergessen“.
Was ISC offengelegt hat
BIND 9 ist die Referenzimplementierung des Domain Name System als Open Source, gepflegt vom Internet Systems Consortium (ISC) und betrieben von Internetdienstleistern, Hosting-Firmen, Unternehmen und Appliance-Herstellern weltweit. Sein named-Daemon beantwortet die DNS-Anfragen, die Hostnamen in IP-Adressen übersetzen. Weil so viel Infrastruktur Namen über BIND auflöst, bleibt ein Fehler darin nicht in einem Netz — er breitet sich auf alles aus, was der Auflösung nachgelagert ist.
Am 16. September 2026 veröffentlichte ISC ein koordiniertes Sicherheitsupdate für 14 CVEs und lieferte BIND 9.20.29 und 9.21.26, um sie zu beheben. Sieben der Probleme sind mit einem CVSS-Wert von 7.5 als hoch eingestuft, sieben als mittel. BIND 9.20.29 adressiert alle vierzehn; BIND 9.21.26 adressiert dreizehn, weil eine der Lücken den 9.21-Entwicklungszweig nicht betrifft. ISC stellte außerdem einen entsprechenden Supported-Preview-Edition-Build für Kunden auf diesem Zweig bereit.
Die auffälligste Lücke ist CVE-2026-77692 (CVSS 7.5), ein nicht authentifizierter Remote-Absturz. Ein Angreifer kann named beenden, indem er eine einzige DNS-over-HTTPS-Anfrage (DoH) überträgt, die einen kryptografisch ungültigen SIG(0)-Signaturdatensatz enthält, und dann die Transportverbindung abrupt schließt. Keine Authentifizierung, keine gültigen Zugangsdaten und keine mehrstufige Exploit-Kette sind erforderlich — eine präparierte Anfrage genügt, um den Resolver auszuschalten, genau die Art billiges, wiederholbares Denial-of-Service-Primitiv, das DNS-Teams nervös macht. Die übrigen hoch eingestuften Probleme sind ebenfalls aus der Ferne auslösbare Abstürze, Speichererschöpfung oder Ressourcenverbrauch. Erreichbar, günstig und auf die Kern-Infrastruktur gerichtet — genau dieses Risikoprofil soll ein Penetrationstest und Security-Audit aufdecken, bevor es ein Angreifer tut. ISC erklärte, keine Kenntnis von einer Ausnutzung der behobenen Fehler in freier Wildbahn zu haben, und empfiehlt ein Update ohne Verzögerung.
Warum ein DNS-Absturz schlimmer ist, als er klingt
Denial-of-Service-Fehler werden leicht unterschätzt. Sie leaken keine Daten und verschaffen einem Angreifer keine Shell, also landen sie unter den Remote-Code-Execution-Schlagzeilen. Doch DNS ist die Ausnahme, die diesen Reflex bricht: Es ist die Abhängigkeit unter jeder anderen Abhängigkeit. Stürzt named ab, stoppt die Namensauflösung, und alles, was einen Hostnamen auflöst, stoppt mit ihr — interne Service-zu-Service-Aufrufe, per DNS adressierte Datenbankverbindungen, Cloud-API-Endpunkte, Webhook-Callbacks, E-Mail-Zustellung und die Eingangstür, an die Ihre Kunden klopfen. Ein Resolver-Ausfall verschlechtert nicht ein Feature; er kann eine ganze Plattform auf einen Schlag ins Leere laufen lassen.
Der DoH-Absturz verschärft das noch. DNS-over-HTTPS wird zunehmend aktiviert, damit Resolver über gewöhnliches HTTPS erreichbar sind — das heißt, die abstürzende Anfrage sieht aus wie normaler verschlüsselter Web-Traffic und kann von überall dort eintreffen, wo der Endpunkt erreichbar ist. Ein einzelnes nicht authentifiziertes Paket, das den Prozess zuverlässig fallen lässt, ist ein Denial-of-Service-Werkzeug, das ein Angreifer wiederholt abfeuern kann und den Resolver so schnell wieder umlegt, wie er neu startet. Ist dieser Resolver ein gemeinsam genutzter interner Resolver oder ein ins Internet gerichteter Dienst, ist der Wirkungsradius jeder Client dahinter.
Die mittelschweren Probleme tragen ein leiseres, aber womöglich fieseres Risiko: Cache-Poisoning und das Einschleusen beliebiger Daten in DNS-Zonen. Wo ein Absturz laut und offensichtlich ist, ist ein vergifteter Cache still — er kann Nutzer und Dienste zu angreiferkontrollierten Adressen lenken, während jedes Dashboard grün bleibt. Das ist der Unterschied zwischen einem Ausfall, den Sie in Sekunden bemerken, und einer Kompromittierung, die Sie tagelang nicht bemerken — weshalb diese niedriger bewerteten Lücken denselben Patch verdienen, keine Verschiebung.
Was das für Software-Teams im DACH-Raum bedeutet
Die erste Lehre: DNS ist Infrastruktur, die Ihnen gehört, kein Versorgungsdienst, den Sie mieten — auch wenn es sich unsichtbar anfühlt. Viele Teams patchen ihre Anwendungsabhängigkeiten nach engem Zeitplan, lassen aber den Resolver aus einem Base-Image, einem Container oder einer Netzwerk-Appliance driften, weil „es einfach läuft“. BIND steckt in mehr Stellen, als eine Asset-Liste üblicherweise erfasst. Jede Instanz zu finden — eigenständige Server, Container und eingebettete Appliances — ist die undankbare Arbeit, die darüber entscheidet, ob dieses Update tatsächlich überall ankommt, wo es muss.
Die zweite Lehre lautet Resilienz by Design, damit ein Absturz kein Ausfall ist. Wenn ein einzelner ausfallender Resolver Ihre Plattform lahmlegt, ist das ein Architekturproblem, das diese CVE nur offengelegt hat. Redundante Resolver, managed DNS mit automatischem Failover, Health-Checks, die ein totes named aus der Rotation nehmen, und enge Grenzen, wer einen DoH-Endpunkt erreichen darf, verwandeln einen one-request-Absturz von einem Geschäftsvorfall in ein Nicht-Ereignis. Gehen Sie davon aus, dass Infrastrukturkomponenten ausfallen; entwerfen Sie so, dass die Namensauflösung überlebt, wenn eine ausfällt.
Drittens ist dies eine Verfügbarkeits- und Integritätspflicht, nicht bloß ein Ops-Ticket. Für EU-Teams macht DORA die IKT-Resilienz und das Management von Drittkomponenten für Finanzunternehmen explizit, und NIS2 — in Deutschland über das NIS2-Umsetzungsgesetz, in Österreich über das NISG und in der Schweiz über die Meldepflichten des ISG umgesetzt — hebt die Messlatte für essenzielle und wichtige Dienste. Für Teams in FinTech und Gesundheit sitzen Verfügbarkeit und Integrität der Kernsysteme direkt in den Erwartungen von BaFin-Aufsicht, ISO 27001 und im BSI-Grundschutz. Ein DNS-Ausfall oder eine vergiftete Zone ist genau das Ereignis, das diese Rahmenwerke verhindern, erkennen und nachweisen lassen wollen. Belegen zu können, welche Resolver die betroffenen Versionen betrieben, wann Sie gepatcht haben und wie die Auflösung bei einem Komponentenausfall stabil bleibt, ist der Nachweis, nach dem Prüfer suchen.
Was jetzt zu tun ist
- Inventarisieren Sie jede BIND-Instanz. Finden Sie alle Resolver und autoritativen Server mit BIND 9 — eigenständige Hosts, Container und Base-Images sowie Appliances oder Produkte, die es einbetten. Die Instanzen, die Sie vergessen, sind die, die verwundbar bleiben.
- Aktualisieren Sie auf die korrigierten Builds. Wechseln Sie auf BIND 9.20.29 oder 9.21.26 (oder den passenden Supported-Preview-Edition-Build). Behandeln Sie ins Internet gerichtete Resolver und alles, was DNS-over-HTTPS bereitstellt, als höchste Priorität, da CVE-2026-77692 nur eine nicht authentifizierte Anfrage benötigt.
- Reduzieren Sie die Exposition, wo Sie nicht sofort patchen können. Beschränken Sie, welche Netze und Clients den DoH-Endpunkt erreichen, drosseln und filtern Sie am Edge und sorgen Sie dafür, dass ein abstürzender Resolver automatisch aus der Rotation genommen wird, damit Clients ein Failover machen statt zu hängen.
- Achten Sie auf Poisoning, nicht nur auf Abstürze. Die mittelschweren Probleme können Daten still in Caches und Zonen einschleusen. Überwachen Sie unerwartete Datensätze, validieren Sie Antworten mit DNSSEC, wo möglich, und alarmieren Sie bei
named-Neustarts und Antwort-Anomalien, nicht nur bei Ausfallzeiten. - Bauen Sie Redundanz ein und testen Sie sie. Betreiben Sie mehr als einen Resolver, erwägen Sie managed oder sekundäres DNS für kritische Zonen und nehmen Sie DNS-Server und ihre offenen Protokolle in den Umfang Ihres nächsten Penetrationstests auf, damit diese Schicht kein blinder Fleck mehr ist.
Häufig gestellte Fragen
Was wurde in BIND 9.20.29 und 9.21.26 behoben?
ISC hat 14 am 16. September 2026 offengelegte Schwachstellen in BIND 9 gepatcht — sieben hoch (CVSS 7.5) und sieben mittel. BIND 9.20.29 behebt alle 14; BIND 9.21.26 behebt 13, da eine Lücke den 9.21-Zweig nicht betrifft. ISC empfiehlt, sofort auf die korrigierten Versionen zu aktualisieren.
Was ist CVE-2026-77692?
Es ist ein nicht authentifizierter Remote-Absturz des BIND-named-Prozesses, eingestuft mit CVSS 7.5. Ein Angreifer beendet den Server, indem er eine einzige fehlerhafte DNS-over-HTTPS-Anfrage mit einem kryptografisch ungültigen SIG(0)-Signaturdatensatz sendet und dann die Verbindung vorzeitig schließt. Eine Anfrage genügt, und es ist keine Authentifizierung nötig — ein günstiger, wiederholbarer Denial-of-Service-Pfad gegen jeden BIND-Resolver mit DoH-Endpunkt.
Werden diese Lücken aktiv ausgenutzt?
Zum Zeitpunkt der Offenlegung am 16. September 2026 erklärte ISC, keine Kenntnis von einer Ausnutzung der behobenen Fehler zu haben. Das ist kein Grund zu warten: Der DoH-Absturz benötigt eine nicht authentifizierte Anfrage, mehrere weitere hoch eingestufte Lücken sind aus der Ferne auslösbare Denial-of-Service-Probleme, und ein DNS-Ausfall kaskadiert über jeden Dienst, der auf Namensauflösung angewiesen ist.
Was erlauben die übrigen BIND-Schwachstellen?
Die verbleibenden hoch eingestuften Probleme lassen entfernte Angreifer Abstürze, Speichererschöpfung oder Ressourcenverbrauch verursachen, alles mit dem Ergebnis Denial of Service. Die mittelschweren Probleme können Cache-Poisoning, übermäßigen Speicher- oder CPU-Verbrauch oder das Einschleusen beliebiger Daten in DNS-Zonen verursachen, über Techniken wie präparierte QTYPE-TKEY-Anfragen, überdimensionierte Negativantworten und SVCB/HTTPS-AliasMode-Datensätze. Cache-Poisoning ist am gefährlichsten, weil es Datenverkehr unbemerkt umleiten kann.
Was sollten Teams tun, die BIND betreiben?
Inventarisieren Sie jeden BIND-Resolver und autoritativen Server, einschließlich Container und Appliances, in denen BIND eingebettet ist, und aktualisieren Sie auf 9.20.29, 9.21.26 oder den passenden Supported-Preview-Edition-Build. Priorisieren Sie ins Internet gerichtete Resolver und DoH-Endpunkte, beschränken Sie den DoH-Zugriff, wo Sie nicht sofort patchen können, betreiben Sie redundantes oder managed DNS, damit ein abstürzender Resolver die Auflösung nicht lahmlegt, und nehmen Sie DNS in den Umfang Ihres nächsten Penetrationstests auf.
Quellen
ISC Knowledge Base — CVE-2026-77692: Unauthenticated remote crash of named via a single DoH SIG(0) request
SecurityWeek — ISC Patches 14 Vulnerabilities in BIND 9 Security Update
The Hacker News — BIND 9 Update Fixes 14 Flaws, Including an Unauthenticated Crash Over DNS-over-HTTPS