摘要

  • 这份留存的报告就 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：等报道的日期被人遗忘，它仍然指向同一个缺陷。

对那些日后必须为这次升级作出交代的部门，经得起时间的教训在于「写下哪些字段」。一份只引用已修复版本清单的处置说明，记录的是「装过什么」，不是「曾暴露什么」，因为暴露从来不是它所引文献的字段。半年后事故复盘要问：在变更窗口之前，哪些系统是脆弱的？那份说明会被当成已经回答过，而它并没有。完整记下构建串（包括任何版本结尾），再记下授权此次变更的文件标识，在当时几乎不花成本，却把「可核验的修复」与「看上去合理的修复」区分开来。

互联网系统联盟的名录条目 是这类缺陷在机构层面的落点，而本文刻意只停在一份记录的内部结构上，不去重复更宽的支持边界议题。真正受影响的范围，这里的报告没有确立，本次取得的其他材料也没有确立：就这一主题的十一次检索中只有两次返回内容，且两次都是同一份报告，未取得任何 ISC 公告、其知识库条目、BIND 9 关于版本声明的参考文档，也未取得任何 CVE 记录——因此在本文实际审阅的材料中，CVE-2025-40778 的受影响版本区间并未确立。会改变这一分类（而非仅仅扩充它）的是两类文件：一是维护方公告或其知识库条目，逐版本线写明受影响区间；二是一条权威 CVE 记录，带有结构化的版本配置。二者任一到手，「various」就会变成一个可检验的字段，这份分析也就会从边界变成比较。