要約

  • 残された報告はCVE-2025-40778について、BIND 9の9.18.41、9.20.15、9.21.14、およびBIND Supported Preview Editionの9.18.41-S1と9.20.15-S1という五つの修正済みビルド文字列を挙げている。
  • 影響側は「various BIND 9 and BIND Supported Preview Edition versions」とのみ記され、範囲は示されていない。したがってこの記録は「修正済み」を支えても、「かつて晒されていた」を支えない。
  • 三つのバージョン系統のうち二つにはプレビュー版の修正文字列があるが、9.21系統にはない。これは一覧の空白であって、当該ビルドについての結論ではない。

技術的な中身を担う一文は短い。残された報告は、この欠陥を重大度「高」と位置づけ、BIND 9のDNSリゾルバに関わるものとし、遠隔から認証なしで攻撃可能で、キャッシュポイズニングによってDNSエントリを操作されると記述している。

その数行後に、同じ文書は欠陥に名前を与えるより重いことをしている。バージョンという問いを二つに割り、片方にだけ答えているのだ。

修正済みの側では、記述は桁まで正確である。報告は五つの文字列を挙げる。BIND 9の9.18.41、9.20.15、9.21.14、そしてBIND Supported Preview Editionの9.18.41-S1と9.20.15-S1である。うち三つはBIND 9の別々の系統から来ており、二つはプレビュー版固有の-S1という末尾を伴う。運用担当が導入済みのビルドをこの一覧に照らせば、明快な答えが出る。一覧の各要素が説明ではなく名前を持つ成果物だからだ。

精度は影響側で止まる。同じ報告は「various BIND 9 and BIND Supported Preview Edition versions」としか述べない。この語は本来バージョン範囲が占める位置に座っており、検証することができない。修正版より四改訂下のビルドが晒されていたのか、あるいは露出が最新リリースから始まったのか、文は何も語らない。

バージョンの話がここで重くなるのは、この欠陥の仕組みによる。キャッシュポイズニングとは、リゾルバ（利用者の代わりに名前解決を行うサーバー）が、攻撃者に細工されたレコードをいったんキャッシュに取り込み、その後の問い合わせに攻撃者の選んだデータで答えてしまうことである。利用者側にはエラーも警告も出ない。返ってくるのは、正しい答えと見分けのつかない誤った答えだ。このように症状が表に出ない欠陥では、何かが起きる前に確かめられる手掛かりはビルド文字列くらいしかないことが多い。

そのため、ある種の読み違いは高くつく。修正版の一覧は出口の一覧であって、露出の地図ではない。第一の向きに読む限り、それは実に有用である。自系統の修正文字列と一致するビルドは、この欠陥について修正済みと見なせる。その判断は推論ではなく公表された文字列に支えられている。第二の向きでは失敗する。古いビルドが修正一覧に無いことは、そのビルドが影響を受けたかどうかについて何も語らない。文書がどれが影響下にあったかを一度も述べていないからだ。一覧を双方向の検査として扱う者は、晒されたホストをお墨付きにするか、立証されていない露出を申告するかのどちらかになる。どちらの誤りも監査の記録に残る。

プレビュー版は別行で見る価値がある。丁寧な比較が壊れるのはそこだからだ。五つの修正のうち二つは、安定版の修正と数字が同じで末尾だけが違う。9.18.41と9.18.41-S1、9.20.15と9.20.15-S1である。数字は一致するが、成果物は一致しない。数字の部分だけを登録する資産管理は、二つの別製品を一行に融合させる。末尾をパッチ水準として読む比較処理は両者の関係を逆転させる。プレビュー版の文字列は安定版ビルドの後続改訂ではないからだ。さらに報告は、三つの系統のうち二つにしかプレビュー版の修正を挙げていない。9.21系統のプレビュー版配備には、この文書の中に照合すべき修正文字列が存在しない。それは一覧の穴であって、そのビルドについての判断ではない。

日付にも同じ規律が要る。残された報告のウェブアドレスには2025年10月28日が含まれるが、本文に並ぶ公開日時の記録はなく、その日は未確認のままであり、本稿のどの論点もその日に依存しない。安定した手掛かりは識別子CVE-2025-40778である。記事の日付が忘れられても、同じ欠陥を指し続ける。

後日アップグレードの説明責任を負う部門にとって、長く効く教訓は「どの欄を書き残すか」にある。修正版の一覧だけを引く是正記録が記録するのは、導入の事実である。露出は記録しない。露出は引用した出所の欄に存在しなかったからだ。半年後にインシデントレビューが「変更作業の前にどのシステムが脆弱だったか」と問うとき、その記録は答えたものとして読まれ、実際には答えていない。ビルド文字列を版の末尾まで含めて書き、変更を承認した文書の識別子を添えることは、その時点ではほとんど費用がかからない。そして検証できる修復と、もっともらしい修復とを分ける。

Internet Systems Consortiumのディレクトリ項目は、この種の欠陥の制度的な受け皿である。本稿はあえて一つの記録の内部構造にとどまり、サポート境界というより広い論点を繰り返さない。実際の影響範囲は、ここに残された報告によっても、本稿で入手した他のいかなる資料によっても確定していない。この主題についての十一回の検索のうち内容が返ったのは二回で、いずれも同じこの一本の報告であり、ISCの勧告、同団体のナレッジベース記事、バージョン表示に関するBIND 9のリファレンス文書、CVEレコードのいずれも得られなかった。したがってCVE-2025-40778の影響バージョン範囲は、本稿が実際に読んだ資料の中では確定していない。この分類を広げるのではなく変えるのは二種類の文書である。系統ごとに影響範囲を記す保守元の勧告またはナレッジベース記事、あるいは構造化されたバージョン設定を持つ権威あるCVEレコードである。どちらかが得られれば「various」は検証可能な欄になり、この分析は境界ではなく比較になる。