Bitcoin Core于2026年11月10日公开中等严重性漏洞CVE-2025-62859：在特定条件下，恶意对等节点可利用紧凑区块中的见证数据可变性，使受害节点的区块处理停滞。29.2和30.0版本已包含修复。理解这一漏洞的关键，是区块重建失败后，节点如何选择下载对象并等待响应。
下载状态清理顺序引出十分钟等待
紧凑区块机制允许节点利用已有交易数据重建区块，减少完整传输的需要。受影响版本在完成重建后，会先清除该紧凑区块的下载状态，再检查见证数据可变性。这里的处理顺序留下了可被利用的窗口。
一旦检查失败，节点会退回完整区块下载流程，通过GETDATA消息向同一个对等节点请求区块，超时时间为10分钟。这意味着，提供异常紧凑区块的节点，仍可能成为后续下载的请求对象。
从这一机制看，漏洞的影响集中在区块处理的可用性：攻击者可以让受害节点等待数据，延后其继续处理区块。已披露的机制并不构成无效区块能够通过验证的证据，也不能据此推导出资产被盗或账本被篡改。
持续停滞依赖连接条件
利用该漏洞有一个重要前提：恶意节点必须率先向受害节点宣告紧凑区块。因此，仅仅存在恶意连接，并不等于每次都能触发停滞；宣告顺序也是攻击能否进入上述回退流程的条件。
如果攻击者控制了受害节点的3个高带宽对等节点，或者受害节点以-blocksonly模式运行，这种停滞可以被反复触发并无限持续。这里的“无限持续”描述的是满足条件后可重复实施的阻塞，不应被理解为一次异常响应就会让所有节点永久停止工作。
我们的判断是，这一事件最值得注意的是下载回退与对等节点选择之间的依赖：验证失败后若继续向同一恶意节点索取数据，等待超时就可能成为攻击手段。对单个节点而言，多次等待可以累积成持续的处理障碍；但现有披露不足以证明比特币网络整体曾因此停摆。
修复先于公开披露一年多落地
该问题由Eugene Siegel发现，并于2025年4月28日向Bitcoin Core安全邮件列表负责任地报告。Gregory Sanders于同年5月30日提交修复提案PR #32646，6月30日合并，9月12日将修复回移至29版本分支。
包含修复的Bitcoin Core 30.0于2025年10月10日发布，29.2于10月14日发布。完整时间线表明，这次公开披露对应的是已有修复版本的历史漏洞，不能把2026年11月的公开日期理解为修复刚刚完成。
时间线还记载，最后仍涉及该漏洞的29.x版本于2026年10月27日结束支持。评估实际暴露情况时，需要区分版本分支与具体修复版本：29.2已经包含补丁，不能仅凭“29.x”这一分支名称就认定其中所有版本都未修复。
风险核对要落到版本与运行方式
对节点运营者而言，首要核对项是实际运行版本是否包含修复，其次是是否启用-blocksonly，以及对等连接是否满足可持续利用的条件。版本决定漏洞是否仍然存在，连接与运行方式则影响攻击能否反复奏效，两者不能相互替代。
这一漏洞的具体风险，是本地节点无法及时完成区块处理，进而可能影响依赖该节点获取最新链状态的服务。是否出现这种影响，仍取决于节点是否遭到利用及停滞持续多久。披露未提供受害节点数量或实际攻击规模，因此，中等严重性评级应与明确的触发条件一起理解，不能直接转换为全网受影响程度。
