Zusammenfassung

  • Der vorliegende Bericht zu CVE-2025-40778 nennt fünf korrigierte Build-Zeichenketten: BIND 9 in den Versionen 9.18.41, 9.20.15 und 9.21.14 sowie BIND Supported Preview Edition in 9.18.41-S1 und 9.20.15-S1.
  • Die betroffene Seite steht nur als „various BIND 9 and BIND Supported Preview Edition versions“, ohne jede Spanne. Der Eintrag trägt damit eine Aussage über die Korrektur, aber keine über die Betroffenheit.
  • Zwei der drei Versionslinien haben einen Preview-Fix, die Linie 9.21 nicht; das ist eine Lücke in der Liste und kein Urteil über diesen Build.

Der Satz, der die technische Substanz trägt, ist kurz. Der vorliegende Bericht stuft die Lücke als hochriskant ein, verortet sie in DNS-Resolvern mit BIND 9 und beschreibt sie als ausnutzbar durch entfernte, nicht authentifizierte Angreifer, mit der Manipulation von DNS-Einträgen durch Cache Poisoning als Wirkung.

Wenige Zeilen später tut dasselbe Dokument etwas Folgenreicheres, als eine Lücke zu benennen: Es teilt die Versionsfrage in zwei Hälften und beantwortet nur eine.

Auf der korrigierten Seite ist die Formulierung auf die letzte Stelle genau. Der Bericht zählt fünf Zeichenketten auf: BIND 9 in 9.18.41, 9.20.15 und 9.21.14 sowie BIND Supported Preview Edition in 9.18.41-S1 und 9.20.15-S1. Drei stammen aus getrennten Versionslinien von BIND 9, zwei tragen die Endung -S1, die zur Preview-Edition gehört. Wer diese Liste gegen den installierten Build hält, bekommt eine klare Antwort, weil jedes Element ein benanntes Artefakt ist und keine Beschreibung.

Genau dort endet die Genauigkeit. Derselbe Bericht schreibt, die Lücke betreffe „various BIND 9 and BIND Supported Preview Edition versions“. Dieses Wort steht an der Stelle, an der sonst eine Spanne steht, und es lässt sich nicht prüfen. Der Satz sagt nicht, ob ein Build vier Revisionen unter dem Fix betroffen war, und auch nicht, ob die Betroffenheit erst mit der jüngsten Auslieferung beginnt.

Warum die Versionsfrage hier so schwer wiegt, liegt an der Wirkung. Cache Poisoning heißt: Ein Resolver nimmt manipulierte Einträge in seinen Cache auf und antwortet danach auf weitere Abfragen mit Daten, die der Angreifer ausgewählt hat. Wer dahinter liegt, sieht keinen Fehler; er bekommt falsche Antworten, die genauso aussehen wie richtige. Wenn das Symptom unsichtbar ist, bleibt vor einem Vorfall oft nur der Build-String als greifbarer Anhaltspunkt — und damit lastet auf der Versionsfrage mehr, als sie allein tragen kann.

Deshalb wird eine bestimmte Lesart teuer. Eine Liste korrigierter Versionen ist eine Ausstiegsliste, keine Karte der Betroffenheit. In die eine Richtung gelesen, ist sie brauchbar: Ein Build, der dem benannten Fix seiner eigenen Linie entspricht, gilt für diese Lücke als korrigiert, und diese Aussage stützt sich auf eine veröffentlichte Zeichenkette statt auf eine Schlussfolgerung. In die andere Richtung gelesen, versagt sie. Fehlt ein älterer Build in einer Liste von Korrekturen, sagt das nichts darüber, ob er betroffen war; das Dokument hat nie festgehalten, welche Builds es waren.

Wer die Liste als Prüfung in beide Richtungen behandelt, spricht entweder einen betroffenen Host frei oder meldet eine Betroffenheit, die niemand belegt hat. Beide Fehler landen in der Prüfspur.

Die Preview-Edition verdient eine eigene Zeile, weil hier sorgfältige Vergleiche brechen. Zwei der fünf Korrekturen tragen dieselben Zahlen wie ein stabiler Fix mit anderer Endung: 9.18.41 neben 9.18.41-S1 und 9.20.15 neben 9.20.15-S1. Die Zahlen stimmen überein, die Artefakte nicht. Ein Inventar, das nur den Zahlenteil erfasst, verschmilzt zwei verschiedene Produkte zu einer Zeile; eine Vergleichsroutine, die die Endung als Patch-Stand liest, kehrt das Verhältnis um, weil der Preview-String keine spätere Revision des stabilen Builds ist. Der Bericht nennt außerdem Preview-Fixes nur für zwei der drei Linien.

Ein Preview-Einsatz auf der Linie 9.21 findet in diesem Dokument also keinen benannten Fix zum Vergleichen. Das ist eine Lücke in der Liste, keine Aussage über den Build.

Das Datum verlangt dieselbe Disziplin. Die Webadresse des vorliegenden Berichts enthält den 28. Oktober 2025, und neben dem Text ist kein Veröffentlichungszeitpunkt festgehalten. Der Tag bleibt damit unbestätigt, und nichts in dieser Analyse hängt an ihm. Der belastbare Anker ist die Kennung CVE-2025-40778; sie zeigt auf dieselbe Lücke, wenn das Artikeldatum längst vergessen ist.

Für die Stelle, die später für das Update geradestehen muss, liegt die dauerhafte Lehre bei den Feldern, die man aufschreibt. Eine Vermerkzeile zur Behebung, die eine Liste korrigierter Versionen zitiert, hält eine Installation fest. Sie hält keine Betroffenheit fest, weil Betroffenheit nie ein Feld der zitierten Quelle war. Wenn eine Vorfallprüfung ein halbes Jahr später fragt, welche Systeme vor dem Änderungsfenster verwundbar waren, wird dieser Vermerk gelesen, als hätte er geantwortet, und er hat es nicht.

Den vollständigen Build-String einschließlich einer Editionsendung zu notieren und die Kennung des Dokuments hinzuzufügen, das die Änderung freigegeben hat, kostet im Moment fast nichts und trennt eine überprüfbare Reparatur von einer plausiblen.

Der Verzeichniseintrag zu Internet Systems Consortium verankert diese Art von Lücke institutionell, und dieser Text bleibt bewusst bei der inneren Struktur eines Eintrags, statt die breitere Frage der Support-Grenze zu wiederholen. Welche Spannen tatsächlich betroffen waren, ist hier weder durch den Bericht noch durch ein anderes beschafftes Dokument belegt: Elf Rechercheversuche zu diesem Thema lieferten zweimal Inhalt, beide Male denselben einzigen Bericht, und weder eine Mitteilung von ISC noch ein Eintrag seiner Wissensdatenbank, weder eine Referenzdokumentation von BIND 9 zur Versionsauskunft noch ein CVE-Eintrag war zu bekommen. Die betroffenen Versionsspannen von CVE-2025-40778 sind damit in dem hier tatsächlich geprüften Material nicht belegt. Zwei Dokumente würden diese Einordnung ändern statt sie nur zu erweitern: eine Mitteilung des Maintainers oder ein Eintrag seiner Wissensdatenbank, der die betroffenen Spannen Linie für Linie nennt, oder ein belastbarer CVE-Eintrag mit strukturierten Versionskonfigurationen. Beides würde aus „various“ ein prüfbares Feld machen, und diese Analyse wäre dann ein Vergleich statt einer Grenze.