Bitcoin Core 已发布 CVE-2025-62861 的官方披露公告。这是节点软件交易中继逻辑中的一个高危缺陷，可能在没有任何明显预警的情况下，使挖矿作业在过期的区块模板上持续运算。该公告将漏洞的发现归功于安全研究员 Niklas Goegge，并将其溯源至一条在错误时机触发、本应保持沉默的中继规则：链重组期间。

受影响版本涵盖 Bitcoin Core 28.0 至 28.2 以及 29.0 至 29.1。修复于 2025 年 10 月发布，但根据项目的协同披露政策，完整技术细节直至 2026 年 11 月才公布。该公告未提及任何停机事件或受影响的运营方；暴露属于历史遗留。指向处于该损坏状态节点的矿机会继续运算，但使用的仍是其收到的最后一个模板，因此新交易及其手续费在有人察觉之前都无法被认领。

链重组如何使交易沦为孤儿

链重组是指节点放弃当前链尖、转向一条竞争性更重的分支。被断开区块中的交易仍然有效，因此 Bitcoin Core 会将它们放回内存池，即未确认交易的暂存区。由于这些交易已在有效区块中确认过，节点会以一个名为 bypass_limits 的标志重新加入它们，该标志会关闭常规的反垃圾和拓扑检查。其目的是忠实地还原内存池，而非重新评判已通过共识的交易。

其中一项本应被关闭的检查涉及第三版本（即 TRUC）交易。根据 BIP 431，一笔 TRUC 交易最多只能有一个未确认的父交易和一个未确认的子交易。这是一项中继政策而非共识规则：区块完全可以合法地包含一个带多个子交易的 TRUC 父交易，尽管任何节点都不会从网络接受这种形状进入其内存池。正是政策与共识之间的这条边界，也划定了漏洞本身的边界：CVE-2025-62861 可能损坏节点的内存池并使其模板输出停滞，但无法产生无效区块或改变链的规则。

自 28.0 版本起，Bitcoin Core 通过一种名为同胞驱逐（sibling eviction）的机制来强制执行单子交易限制。当一笔新交易会使某个 TRUC 父交易拥有第二个未确认子交易时，节点会将现有子交易视为替换候选，若新交易支付的手续费足够，则按费用替换（replace-by-fee）规则将其驱逐。

漏洞在于：即使 bypass_limits 已被设置，同胞驱逐仍会运行。一次恢复了拥有多个子交易的 TRUC 父交易（这种形状在断开的区块内完全有效）的链重组，可能触发对其中一笔被恢复交易的驱逐，而花费其输出的交易却仍留在内存池中。于是内存池中出现了这样的子交易：其父交易已无处存在——既不在链上，也不在池中。

Greg Sanders 的修复将 TRUC 检查以 bypass_limits 作为门控条件，因此驱逐机制在链重组还原期间不再运行。相关拉取请求 PR #33504 还补充了原代码缺失的测试场景：交易来自被断开的区块而非来自对等节点。

从挖矿角度看模板停滞时的表现

节点通过 getblocktemplate 向挖矿软件分配工作：组装候选区块，执行节点自身的有效性检查，并返回前一区块哈希、选定交易以及下一个高度。当内存池中存在无父交易时，组装出的候选区块无法通过该检查，因此该调用无法返回新的工作。

从外部看，节点显得一切正常：

• 进程正在运行
• 对等连接保持打开
• 链尖持续推进
• 内存池接受新交易

实际已损坏的部分：

• 模板请求返回错误
• 矿机（Hasher）继续在过期工作上运算
• 在当前链尖上无法找到区块
• 该状态持续存在，直至节点重启

通用监控面板所关注的一切指标都会保持绿色。网络也不会传回任何信号：链尖仍在推进——区块仍不断被发现，只是并非由这台设备挖出——因此代价全部落在停滞的矿工身上：算力无法在当前链尖上产出区块，本可认领的手续费也随之流失。矿工从节点需要的唯一东西——最新的模板——恰恰是它已停止产出的东西。

重启、补丁与生命周期终结

重启节点会以一致的状态从磁盘重新加载内存池，从而消除症状。但这无济于解决根因：下一次出现相同交易形状的链重组仍可能使节点再度停滞。

根因在三个版本中被移除。30.0 版本于 2025 年 10 月 10 日携修复发布，随后在 29.2 和 28.3 中提供了向后移植。从私密报告到最后一个版本发布历时三周：

两个向后移植分支此后均已退出支持。Bitcoin Core 的维护政策覆盖最新的三个大版本——目前为 30.x、31.x 和 32.x——而 29.x 已于 2026 年 10 月 27 日结束生命周期。当初对故障仅以重启应对而未采取其他措施的运营方，如今运行的是已不受支持的代码，而触发该漏洞的确切交易形状已被公开描述。

公告为何等待了 396 天

从首个修复版本发布到详细公告发布历时 396 天，且公告恰在 29.x 结束生命周期两周后发布。这两个数字都不是巧合。Bitcoin Core 的披露政策规定：中、高危漏洞的细节将保留至最后一个受影响版本失去支持两周之后，并在那之前两周发布预告，时间与大版本发布相配合。

保密涵盖的是解释说明，而非代码。该拉取请求自 2025 年 9 月 29 日起就已公开，28.3 和 29.2 的发布说明当时也列出了内存池修复。保密一年的是那份将该补丁与可复现的挖矿停滞联系起来的技术说明。

该政策确实提供了更快的通道。被归类为"易于发现"的漏洞——项目将其定义为仅需极低代价即可发现的漏洞——会立即发布点版本和公告，不做保密。此漏洞走的是标准时间表，说明维护者并不认为它容易被发现。它与其他两份高、中危公告于同一天发布，分别涉及区块处理停滞和 Tor 权限错误；三者均已在 2025 年 10 月的同一发布周期中修复。因此，任何新到足以包含该内存池补丁的构建版本，也同时带有另外两项修复。

这条较慢通道本身蕴含着一个假设：运营方会在一年的窗口期内完成升级，因此当触发条件被公开描述时，已没有易受影响的节点仍在运行。

应当监控什么而非在线状态

对挖矿作业而言，有效的检查不是节点是否存活，而是其最近一次成功获取模板的时间有多久。一个运行中、已连接且已同步的进程，仍可能已停止分配工作，而该漏洞正是这种情况可能静默发生的途径之一。构建版本应纳入同一检查，因为今天模板获取正常的节点，明天可能就是失去支持的节点。

备用模板来源也需要接受同样的检验。运行相同版本、相同内存池政策的故障切换节点，会遭遇同样的链重组和同样的停滞；两个运行中的进程并不等于两个独立的工作来源。只有运行于不同、已打补丁的构建版本的节点，才能让作业持续挖矿；而只有事先在模拟链重组下进行过测试的运营方，才能提前知晓这一点。