Die kurze Antwort
ISC hat 14 Schwachstellen in BIND 9 geschlossen, und eine davon lässt jeden im Internet Ihren DNS-Server mit einer einzigen Anfrage abstürzen. CVE-2026-77692 (CVSS 7.5) missbraucht DNS-over-HTTPS: eine präparierte Anfrage mit einem ungültigen SIG(0)-Record, gefolgt von einem vorzeitigen Verbindungsabbruch, löst eine NULL-Pointer-Dereferenzierung aus und beendet den named-Prozess. Keine Authentifizierung, keine gültigen Zugangsdaten, kein Vorabzugriff — nur ein fehlerhaftes Paket. Fällt DNS aus, fällt alles aus, was darüber auflöst — deshalb gehört das diese Woche ganz oben in Ihre Cloud- und DevOps-Patch-Queue.
Der Fix ist unkompliziert — ein Upgrade auf BIND 9.20.29 oder 9.21.26 — doch die Lehre ist grundsätzlicher. Autoritatives und rekursives DNS ist kritische Infrastruktur, die viele Teams als „einmal einrichten und vergessen" behandeln. Dieses Release erinnert daran, DNS im selben Takt wie den Anwendungs-Stack zu patchen, es auf Abstürze zu überwachen und sicherzustellen, dass eine einzige Randanfrage keinen Dienst lahmlegen kann, von dem das ganze Unternehmen abhängt.
Was ISC gepatcht hat — und die entscheidende Lücke
Am 16. September hat das Internet Systems Consortium — die gemeinnützige Organisation, die BIND, die am weitesten verbreitete DNS-Serversoftware im Internet, pflegt — BIND 9.20.29 und 9.21.26 veröffentlicht und damit 14 Sicherheitslücken auf einen Schlag geschlossen. Sieben sind als hoch, sieben als mittel eingestuft. Die hoch eingestufte Gruppe lässt sich aus der Ferne ausnutzen, um Programmabstürze, Speichererschöpfung oder Ressourcenerschöpfung auszulösen; die mittelschweren Probleme umfassen Cache-Poisoning, CPU-Erschöpfung und das Einschleusen beliebiger Daten in DNS-Zonen.
Herausragend ist CVE-2026-77692 mit CVSS 7.5. Sie lässt einen nicht authentifizierten, entfernten Angreifer den named-Daemon beenden, indem er eine einzige DNS-over-HTTPS-Anfrage (DoH) mit einem kryptografisch ungültigen SIG(0)-Record sendet und die Transportverbindung abrupt schließt, bevor die Validierung abgeschlossen ist. Das Ergebnis ist eine NULL-Pointer-Dereferenzierung, die den Prozess abbricht — ein sauberer Denial of Service ohne Login, ohne Session und ohne gültige Signatur. Für ins Internet gerichtete Resolver ist das nahezu das schlechtestmögliche Verhältnis von Aufwand zu Wirkung.
ISC erklärt, ihm sei keine der 14 Schwachstellen als in freier Wildbahn ausgenutzt bekannt. Das beruhigt, ist aber zeitlich begrenzt: Das Konsortium weist zugleich darauf hin, dass Tests zur Reproduktion der Lücken öffentlich sind, was den Aufwand für einen Angreifer stark senkt. Wenn ein Proof-of-Concept-Pfad bereits dokumentiert ist, ist „noch nicht ausgenutzt" ein terminliches Detail, kein Grund zum Aufschieben. Wer BIND betreibt, sollte dies als Maßnahme derselben Woche behandeln und in eine disziplinierte Sicherheits- und Patch-Routine einbetten.
Warum DNS-over-HTTPS die Angriffsfläche vergrößert
DNS-over-HTTPS wurde entwickelt, um die Privatsphäre zu verbessern, indem DNS-Anfragen in verschlüsselten HTTPS-Verkehr gehüllt werden, und seine Verbreitung über Unternehmens-Resolver und öffentliche DNS-Anbieter ist stetig gewachsen. Aber jeder neue Transport, den ein Server spricht, ist neuer Code, der nicht vertrauenswürdige Eingaben parst — und CVE-2026-77692 sitzt genau in dieser Naht: der Behandlung von SIG(0)-Transaktionssignaturen über den DoH-Transport. Die Lücke liegt nicht in der DNS-Auflösungslogik selbst, sondern darin, wie der Server eine Verbindung verwaltet, die mitten in der Validierung abgebrochen wird.
Dieses Muster — ein Absturz, ausgelöst durch fehlerhafte Eingaben plus vorzeitigen Verbindungsabbruch — ist eine wiederkehrende Fehlerklasse in Netzwerk-Daemons und genau der Grund, warum das Parsen von Eingaben auf randseitigen Diensten besondere Aufmerksamkeit verdient. Wenn Ihre Resolver DoH exponieren, sind sie über gewöhnliche HTTPS-Ports erreichbar, die Firewalls in der Regel offen lassen — das mentale Modell „interner Dienst" schützt Sie also nicht. Praktisch heißt das: Wissen Sie, welche Transporte jeder DNS-Endpunkt tatsächlich spricht, und behandeln Sie jeden davon als Angriffsfläche, die Patches und Monitoring braucht.
Es untermauert außerdem ein Designprinzip für jeden Dienst, der nicht vertrauenswürdige Verbindungen terminiert: Geh davon aus, dass Clients sich falsch verhalten, vorzeitig trennen und absichtlich ungültige Daten senden. Robuste Verwaltung des Verbindungslebenszyklus — und Crash-Restart-Supervision als Rückfallebene — ist keine Luxusausstattung, sondern der Unterschied zwischen einem protokollierten Fehler und einem unternehmensweiten Ausfall.
Was das für DACH-Teams bedeutet
Die erste Implikation ist ein Blast-Radius-Problem. DNS ist eine Abhängigkeit von fast allem: Service Discovery, API-Aufrufe, E-Mail, Zertifikatsvalidierung und kundennaher Verkehr setzen alle voraus, dass die Auflösung funktioniert. Ein Absturz in named lässt nicht ein Feature ausfallen; er kann in Timeouts über eine ganze Plattform kaskadieren. Für Teams in FinTech, HealthTech oder E-Commerce, wo Verfügbarkeit vertraglich zugesichert und Ausfallzeit in Umsatz und regulatorischem Risiko gemessen wird, ist ein unautorisierter DoS im DNS eine Frage der Geschäftskontinuität, nicht bloß ein Ops-Ticket.
In der DACH-Region kommt eine regulatorische Dimension hinzu: Das BSI und das zugehörige CERT-Bund veröffentlichen zu solchen BIND-Advisories eigene Warnmeldungen, und Betreiber Kritischer Infrastrukturen (KRITIS) unterliegen nach dem BSI-Gesetz Melde- und Absicherungspflichten. Mit der laufenden Umsetzung von NIS-2 in Deutschland, Österreich und der Schweiz weitet sich der Kreis der Organisationen, die Verfügbarkeit und Meldewege für DNS-Dienste nachweisen müssen, spürbar aus. Wer DNS-Resolver in einem KRITIS- oder NIS-2-relevanten Umfeld betreibt, sollte dieses Release nicht nur technisch, sondern auch dokumentarisch sauber abarbeiten — Patch-Zeitpunkt, betroffene Systeme und Gegenmaßnahmen festhalten.
Die zweite Implikation betrifft die Verantwortlichkeit. Viele Organisationen wissen nicht, wer ihr DNS patcht. Es kann ein Managed-Provider, ein Plattform-Team, eine Appliance oder ein Container-Image sein, das seit Monaten niemand neu gebaut hat. Dieses Release ist ein guter Anlass, eine einfache Frage zu beantworten: Wer ist für jeden DNS-Resolver und autoritativen Server, von dem wir abhängen, für das Einspielen von BIND 9.20.29 oder 9.21.26 zuständig — und bis wann? Unklare Verantwortung ist der Grund, warum eine dokumentierte, patchbare Lücke monatelang überlebt.
Die dritte Implikation ist Resilienz als Standard. Auch nach dem Patch wird die nächste DNS-Lücke irgendwann kommen. Teams, die named unter einem Prozess-Supervisor betreiben, die Auflösung über redundante Instanzen verteilen, DoH-Endpunkte mit Rate-Limiting versehen und bei wiederholten Neustarts alarmieren, fangen die nächste Absturz-Lücke mit einem Zucken statt einem Ausfall ab. Das ist die Haltung, die wir in jede Individualsoftware-Plattform einbauen: Die kritischen Dienste sind überwacht, redundant und beobachtbar, sodass ein einzelner Ausfall kontrolliert degradiert, statt das System lahmzulegen.
Was jetzt zu tun ist
- Inventarisieren Sie Ihren BIND-Bestand. Finden Sie jeden rekursiven und autoritativen Server, inklusive Appliances und Container-Images. Man kann nicht patchen, was man nicht gefunden hat.
- Upgraden Sie auf das Fix-Release. Wechseln Sie auf BIND 9.20.29 oder 9.21.26 (bzw. 9.20.29-S1 für die Supported Preview Edition) im von Ihnen genutzten Zweig. Prüfen Sie die laufende Version nach dem Deployment, nicht nur die Paketversion.
- Reduzieren Sie die DoH-Exposition. Beschränken Sie, welche Clients DNS-over-HTTPS-Endpunkte erreichen, und setzen Sie Resolver hinter Rate-Limiting und Netzwerkkontrollen, damit eine Flut präparierter Anfragen den Dienst nicht wiederholt zum Absturz bringen kann.
- Beaufsichtigen und überwachen Sie
named. Betreiben Sie ihn unter systemd oder Äquivalent, das ihn automatisch neu startet, und alarmieren Sie bei wiederholten Abstürzen, statt sie aus einer Kundenmeldung zu erfahren. - Legen Sie klare Verantwortlichkeit fest. Benennen Sie das Team, das für das DNS-Patching zuständig ist, und nehmen Sie BIND in denselben Review-Takt wie Ihre Anwendungsabhängigkeiten auf, damit das nächste Advisory Routine ist und kein Feueralarm.
Häufig gestellte Fragen
Was hat ISC am 16. September 2026 in BIND 9 gepatcht?
ISC hat BIND 9.20.29 und 9.21.26 veröffentlicht, um 14 Schwachstellen zu beheben — sieben hoch und sieben mittel eingestuft. Die hoch eingestuften Probleme können entfernte Abstürze, Speichererschöpfung oder Ressourcenerschöpfung auslösen; die mittelschweren umfassen Cache-Poisoning, CPU-Erschöpfung und das Einschleusen beliebiger Daten in DNS-Zonen.
Was ist CVE-2026-77692?
Es ist eine hoch eingestufte Schwachstelle (CVSS 7.5), die einen nicht authentifizierten, entfernten Angreifer den named-Dienst mit einer einzigen DNS-over-HTTPS-Anfrage zum Absturz bringen lässt. Der Angreifer sendet eine präparierte DoH-Anfrage mit einem kryptografisch ungültigen SIG(0)-Record und schließt die Verbindung vorzeitig, was eine NULL-Pointer-Dereferenzierung und einen Denial of Service auslöst.
Welche BIND-9-Versionen sind betroffen und behoben?
CVE-2026-77692 betrifft BIND 9.20.0 bis 9.20.27, 9.21.0 bis 9.21.25 und die Supported Preview Edition 9.20.9-S1 bis 9.20.27-S1. Die Fixes stecken in BIND 9.20.29, 9.21.26 und 9.20.29-S1. Upgraden Sie auf das Fix-Release des von Ihnen genutzten Zweigs.
Wird CVE-2026-77692 aktiv ausgenutzt?
ISC erklärte, ihm sei keine der 14 Schwachstellen als in freier Wildbahn ausgenutzt bekannt. Es wies jedoch darauf hin, dass Tests zur Reproduktion öffentlich sind, was den Aufwand zur Waffenwerdung senkt — Betreiber sollten also zeitnah patchen statt zu warten.
Was, wenn wir BIND nicht sofort patchen können?
Reduzieren Sie die Angriffsfläche, während Sie das Upgrade planen: Beschränken Sie den Zugriff auf DoH-Endpunkte, setzen Sie Resolver hinter Rate-Limiting und Netzwerkkontrollen, betreiben Sie named unter einem Supervisor, der ihn automatisch neu startet, und überwachen Sie wiederholte Abstürze. Diese Maßnahmen begrenzen den Schaden, ersetzen aber nicht das Einspielen von BIND 9.20.29 oder 9.21.26.
Quellen
ISC — 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