Unbound und BIND 9: DNSSEC-Lücke und 14 Fehler gepatcht

Am 16. September 2026 haben zwei Projekte, die zusammen den Großteil der rekursiven DNS-Auflösung im Internet tragen, am selben Tag Sicherheitsupdates veröffentlicht. NLnet Labs meldet in Unbound einen als kritisch eingestuften Heap-Overflow im DNSSEC-Validator, der eine Codeausführung ermöglichen kann. Das Internet Systems Consortium (ISC) schließt in BIND 9 vierzehn Schwachstellen, darunter einen Absturz, den ein Angreifer ohne jede Anmeldung mit einer einzigen DNS-over-HTTPS-Anfrage auslösen kann.

Betroffen ist, wer einen eigenen rekursiven Resolver oder einen eigenen autoritativen Nameserver betreibt: Unbound auf pfSense und OPNsense, Unbound hinter einem Pi-hole, BIND auf Linux-Servern in Rechenzentren oder im Firmennetz. Nicht betroffen ist, wer DNS-Anfragen ohne eigenen Validator einfach an den Resolver des Providers oder an einen öffentlichen Dienst weiterreicht. Wer einen eigenen Resolver betreibt, sollte heute die Version prüfen. Ein Notfall-Wartungsfenster außerhalb der Geschäftszeiten ist bei der Unbound-Lücke vertretbar, bei BIND reicht in den meisten Umgebungen das nächste reguläre Fenster. Aktive Angriffe sind nach Angaben beider Projekte bislang nicht bekannt.

Was ist passiert?

NLnet Labs hat am 16. September 2026 Unbound 1.26.1 veröffentlicht und dazu neun Sicherheitsmeldungen publiziert. Die schwerwiegendste ist CVE-2026-81642. Laut Advisory kann ein DNSKEY-Eintrag, dessen Owner-Name ein Kompressionszeiger in die eigenen RDATA ist, beim Bilden des Digests den Puffer überlaufen lassen. Der Angriffsweg ist im Advisory klar beschrieben: Ein Angreifer kontrolliert eine präparierte Zone und bringt den verwundbaren Resolver dazu, diese Zone abzufragen. Als Auswirkung nennt NLnet Labs Denial of Service und eine mögliche Remote Code Execution über vom Angreifer kontrollierte Daten.

Gefunden und gemeldet wurde die Lücke von Yuqi Qiu und Xiang Li vom AOSP Lab der Nankai-Universität. NLnet Labs stuft sie selbst als Critical ein. Der in der Berichterstattung genannte CVSS-Wert von 9.1 stammt vom Projekt selbst, nicht aus einer abgeschlossenen NVD-Analyse. Eine zweite Meldung derselben Runde, CVE-2026-82717, betrifft eine Heap-Korruption bei der CNAME-Synthese und kann laut NLnet Labs unter bestimmten Systemen und Kompilieroptionen ebenfalls zu Codeausführung führen.

Das ISC hat am selben Tag BIND 9.20.29 und 9.21.26 veröffentlicht und dazu vierzehn einzelne Advisories in seiner Knowledge Base publiziert. Die 9.20.29 behebt alle vierzehn, die Entwicklerversion 9.21.26 dreizehn davon, weil CVE-2026-19662 den 9.21-Zweig nicht betrifft. Die Versionsnummer springt von 9.20.27 direkt auf 9.20.29, weil das ISC die 9.20.28 vor der Veröffentlichung wegen einer im Test gefundenen Regression zurückgezogen hat.

Wer ist betroffen?

Die Betroffenheit lässt sich an einer einzigen Frage festmachen: Läuft im eigenen Netz Software, die DNS-Antworten selbst auflöst oder selbst signierte Daten prüft?

Unbound bis einschließlich 1.26.0: NLnet Labs nennt für CVE-2026-81642 keinen einschränkenden Konfigurationsvorbehalt. Betroffen sind damit auch das Sicherheitsrelease 1.25.2 vom Juli und die im August veröffentlichte 1.26.0.
pfSense und OPNsense: Beide Firewall-Distributionen setzen Unbound als Standard-Resolver ein. Wer den DNS Resolver-Dienst aktiviert hat, betreibt einen betroffenen Dienst und muss auf ein Distributions-Update warten oder selbst aktualisieren.
Pi-hole mit Unbound als Upstream: Die verbreitete Kombination aus Pi-hole für die Filterung und lokalem Unbound für die eigentliche Auflösung ist betroffen. Pi-hole selbst ist es nicht.
BIND 9.20.0 bis 9.20.27 und 9.21.0 bis 9.21.25: Das sind die beiden aktiv gepflegten Zweige. Zwölf der vierzehn Schwachstellen betreffen zusätzlich den alten 9.18-Zweig bis einschließlich 9.18.50.
BIND 9.18: Dieser Zweig ist seit Ende Juni 2026 abgekündigt. 9.18.50 war das letzte Release, ein Fix wird es nicht geben. Die Schwachstellenmatrix des ISC führt für alle vierzehn Einträge in der 9.18-Spalte schlicht EOL.
Distributionspakete: Debian 12 liefert ein Paket auf Basis von 9.18.49. Wer BIND aus der Distribution betreibt, hängt an deren Backport-Zeitplan und nicht am ISC-Release.

Nicht betroffen ist eine Umgebung, in der Clients und Server ihre Anfragen unverändert an den Resolver des Internetproviders, an einen öffentlichen Resolver oder an einen Windows-DNS-Server weiterreichen, der selbst nur weiterleitet. Ohne eigenen Validator und ohne eigenen rekursiven Dienst gibt es den verwundbaren Codepfad im eigenen Netz nicht.

Wie kritisch ist das?

Die beiden Meldungen unterscheiden sich in der Qualität des Angriffspfads deutlich. Bei Unbound geht es um eine mögliche Remote Code Execution im Kontext des Resolver-Prozesses, also um vollständige Kompromittierung eines Dienstes, der im Netz eine zentrale Vertrauensrolle einnimmt. Der Aufwand für den Angreifer ist überschaubar: eine eigene, bösartige Zone betreiben und den Resolver dazu bringen, sie abzufragen. Ein Nutzerklick auf einen Link mit einem Hostnamen aus dieser Zone genügt dafür in der Regel.

Bei BIND liegt der Schwerpunkt auf Denial of Service. Das ISC bewertet sieben der vierzehn Meldungen mit 7.5 nach CVSS 3.1 als hoch, die übrigen sieben zwischen 5.3 und 6.5 als mittel. Herausragend ist CVE-2026-77692: Ein Absender ohne jede Berechtigung kann den Prozess named zum Abbruch bringen, indem er eine DNS-over-HTTPS-Anfrage mit einem kryptografisch ungültigen SIG(0)-Eintrag sendet und die Verbindung vorzeitig schließt. Der Vektor lautet CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H. Das ISC nennt für keine der vierzehn Meldungen einen Workaround, es gibt also nur den Weg über das Update.

Vier der vierzehn BIND-Meldungen zielen nicht auf Verfügbarkeit, sondern auf die Integrität der DNS-Daten. Bei CVE-2026-19941 kann ein signierter NSEC-Eintrag aus einer fremden Zone als Beweis dafür durchgehen, dass kein Wildcard existiert, sodass eine gefälschte NXDOMAIN-Antwort die DNSSEC-Validierung besteht. Bei CVE-2026-77119 lässt sich über einen NSEC3-Eintrag aus einer Nachbarzone eine sichere Delegation als unsigniert ausgeben. Das ISC beschreibt beide Ergebnisse als Cache Poisoning. Solche Fehler sind operativ unauffällig und deshalb gefährlicher, als eine reine Absturzmeldung wirkt.

Beide Projekte geben an, keine aktive Ausnutzung zu kennen. Zur Unbound-Lücke war der CISA-Eintrag am Veröffentlichungstag mit einem Ausnutzungsstatus von none versehen, die NVD-Analyse stand noch aus. Gleichzeitig veröffentlicht das ISC seit Mai 2026 zu jeder Schwachstelle Reproduktionstests. Der Quellbaum von 9.20.29 enthält Systemtests für mehrere der Meldungen, unter anderem einen, der eine ungültige SIG(0)-Anfrage über DoH sendet und die Verbindung schließt. Das sind keine Angriffswerkzeuge, sie benennen die Auslösebedingungen aber sehr genau.

Die wichtigsten CVEs im Überblick

Die folgende Tabelle fasst die schwerwiegendsten Meldungen beider Projekte zusammen. Alle Angaben stammen aus den Advisories von NLnet Labs und der ISC Knowledge Base, die Bewertungen sind die der jeweiligen Hersteller.

CVE	Produkt	Einstufung	Auswirkung	Behoben in
CVE-2026-81642	Unbound	Critical	Heap-Overflow im DNSSEC-Validator, Denial of Service und mögliche Codeausführung	1.26.1
CVE-2026-82717	Unbound	High	Heap-Korruption bei CNAME-Synthese, Codeausführung je nach System und Kompilieroptionen möglich	1.26.1
CVE-2026-81634	Unbound	High	Heap-Overflow bei der DNSSEC-Kanonisierung, Denial of Service	1.26.1
CVE-2026-77692	BIND 9	High, CVSS 7.5	Unauthentifizierter Absturz von named über eine DoH-Anfrage mit ungültigem SIG(0)	9.20.29 und 9.21.26
CVE-2026-76163	BIND 9	High, CVSS 7.5	Absturz von named durch eine TKEY-Anfrage, wenn named.conf keinen globalen options-Block hat	9.20.29 und 9.21.26
CVE-2026-19667	BIND 9	High, CVSS 7.5	Absturz des Resolvers in Standardkonfiguration durch eine präparierte negative Antwort	9.20.29 und 9.21.26
CVE-2026-19941	BIND 9	Medium	Gefälschte NXDOMAIN-Antwort besteht die Validierung, vom ISC als Cache Poisoning eingestuft	9.20.29 und 9.21.26
CVE-2026-19033	BIND 9	Medium	Sekundärserver liefert Zonendaten aus einem IXFR aus, ohne dass jede Nachricht per TSIG signiert war	9.20.29 und 9.21.26

Was sollten Admins jetzt tun?

Die Reihenfolge ist wichtig. Zuerst klären, ob überhaupt ein eigener Resolver läuft, dann die Version bestimmen, dann patchen.

Bestand klären: Prüfen, welche Systeme im Netz selbst rekursiv auflösen. Typische Kandidaten sind Firewalls mit pfSense oder OPNsense, ein Pi-hole-Host mit lokalem Unbound, Linux-Server mit named und interne autoritative Nameserver.
Version prüfen: Auf Linux-Systemen liefern unbound -V und named -v die installierte Version. Alles bei Unbound bis einschließlich 1.26.0 und bei BIND bis einschließlich 9.20.27 beziehungsweise 9.21.25 ist betroffen.
Patchstand des Distributionspakets abgleichen: Die ISC-Version allein reicht nicht als Nachweis. Entscheidend ist, ob das Paket der eigenen Distribution die Fixes bereits als Backport enthält.
Hochrisikosysteme zuerst: Priorität haben Resolver, die aus dem Internet erreichbar sind, sowie BIND-Instanzen mit aktivem DNS-over-HTTPS. Danach folgen interne Resolver, zuletzt Testsysteme.
BIND 9.18 planen, nicht patchen: Für den abgekündigten Zweig gibt es keinen Fix. Hier ist der Umstieg auf 9.20 das einzige wirksame Mittel, und er gehört in die laufende Planung, nicht in den nächsten Jahresplan.
Erreichbarkeit einschränken: Rekursive Resolver gehören nicht offen ins Internet. Die Firewall-Regeln für Port 53 auf UDP und TCP sowie für DoH auf 443 prüfen und auf die tatsächlich nötigen Quellnetze begrenzen.
Logs sichten: Bei BIND auf unerwartete Neustarts von named achten, etwa über journalctl -u named --since "7 days ago". Wiederholte Abstürze ohne erkennbaren Anlass sind ein Grund, genauer hinzusehen.
Geändertes Verhalten einplanen: Mit dem Fix für CVE-2026-85501 hat NLnet Labs die Voreinstellung val-clean-additional auf aus gesetzt. Unbound validiert DNSSEC-Daten im Additional-Abschnitt einer Antwort damit standardmäßig nicht mehr. Wer diese Prüfung braucht, muss sie nach dem Update ausdrücklich setzen.
Konfiguration vor dem Neustart sichern: Vor dem Update eine Kopie von /etc/unbound/ beziehungsweise /etc/bind/ ablegen, damit ein Rückfall auf den alten Stand ohne Rekonstruktion möglich bleibt.

Die Versionsprüfung auf einem Linux-Host sieht so aus:

# Installierte Unbound-Version anzeigen
unbound -V | head -n 1

# Installierte BIND-Version anzeigen
named -v

# Paketstand der Distribution gegenpruefen, hier fuer Debian und Ubuntu
apt-cache policy unbound bind9

# Laeuft der Dienst ueberhaupt und seit wann
systemctl status unbound --no-pager
systemctl status named --no-pager

Nach dem Update lohnt eine kurze Funktionsprüfung, damit ein stiller Konfigurationsfehler nicht erst im Tagesbetrieb auffällt:

# Konfiguration von Unbound pruefen, bevor der Dienst neu startet
unbound-checkconf /etc/unbound/unbound.conf

# Konfiguration von BIND pruefen
named-checkconf /etc/bind/named.conf

# Aufloesung und DNSSEC-Validierung gegen den lokalen Resolver testen
dig @127.0.0.1 +dnssec example.com A

Eine erfolgreiche Validierung erkennt man in der Ausgabe von dig am Flag ad in der Flags-Zeile. Fehlt es bei einer signierten Zone, prüft der Resolver nicht oder die Validierung schlägt fehl.

Einordnung für Unternehmen

Für kleine und mittlere Unternehmen ist die praktische Betroffenheit oft geringer als die Schlagzeile vermuten lässt. Wer DNS über den Provider oder über einen Windows-DNS-Server mit reiner Weiterleitung betreibt, hat den verwundbaren Code nicht im Haus. Wer dagegen aus Datenschutz- oder Filtergründen bewusst einen eigenen Resolver aufgebaut hat, trägt genau dafür jetzt die Wartungslast. Das ist kein Argument gegen eigene Resolver, sondern eines dafür, sie im Patchmanagement wie jeden anderen exponierten Dienst zu führen.

Bemerkenswert ist die Frequenz. Das ISC hat im Jahr 2026 fünf BIND-Sicherheitsreleases veröffentlicht, mit einer, vier, sechs, neun und nun vierzehn behobenen Schwachstellen. Das ISC selbst hat im Mai angekündigt, dass Anwender für den Rest des Jahres in jedem monatlichen Wartungsrelease mit Sicherheitsfixes rechnen sollten, und nennt als Grund eine stark gestiegene Zahl von Schwachstellenmeldungen, die mit großen Sprachmodellen erzeugt wurden. Praktisch heißt das: Ein jährliches Update-Fenster für DNS-Dienste reicht nicht mehr. Ein monatlicher Rhythmus mit einer kurzen Prüfung der Herstellerseite ist der angemessene Aufwand.

Wer DNS-Dienste betreibt, sollte außerdem einen zweiten, unabhängigen Resolver vorhalten. Fällt ein Resolver durch einen Absturz aus, ist im Firmennetz sofort alles betroffen, von der Anmeldung am Verzeichnisdienst bis zum Mailversand. Zwei getrennte Instanzen auf getrennten Hosts sind die einfachste Absicherung gegen genau die Denial-of-Service-Klasse, die in diesem BIND-Release dominiert.

Passende Anleitungen auf S-EDV

Pi-hole als Werbeblocker und DNS-Server mit Docker einrichten: zeigt den Aufbau, bei dem Unbound häufig als Upstream-Resolver dahinter steht.
DNS-Records erklärt: A, AAAA, CNAME, MX und TXT: Grundlagen zu den Eintragstypen, die in den Advisories als Auslöser auftauchen.
pfSense und OPNsense: Firewall-Erstkonfiguration: hier wird der Unbound-Resolver auf der Firewall eingerichtet, der von der Lücke betroffen sein kann.

Quellen

NLnet Labs: Unbound Security Advisories, Primärquelle zu CVE-2026-81642, CVE-2026-81634 und den weiteren Meldungen des 1.26.1-Releases, abgerufen am 18.09.2026.
NLnet Labs: Advisory-Text zu CVE-2026-81642 mit Beschreibung, betroffenen Versionen und Patch-Anleitung.
ISC Knowledge Base: CVE-2026-77692, Primärquelle zu CVSS-Wert, Vektor, betroffenen Versionen und fehlendem Workaround.
ISC: BIND 9 Security Vulnerability Matrix mit allen vierzehn Einträgen vom 16.09.2026 und dem EOL-Status des 9.18-Zweigs.
SecurityWeek: ISC Patches 14 Vulnerabilities in BIND 9 Security Update vom 17.09.2026.
The Hacker News: Critical Unbound DNSSEC Validator Flaw Could Allow RCE via a Malicious DNS Zone vom 17.09.2026.
The Hacker News: BIND 9 Update Fixes 14 Flaws, Including an Unauthenticated Crash Over DNS-over-HTTPS vom 17.09.2026.