Bitcoin Core 将更快披露部分漏洞，节点运营者能否及时更新？

在开发者发现某些漏洞只需极少的努力就能被重新发现——包括向 AI 模型输入一个简单的提示词——之后，Bitcoin Core 更改了其安全披露政策。

该项目的10 月 22 日政策更新为这些漏洞创建了一条更快的途径。维护者计划尽快为每个受支持的主要版本发布一个点版本，并在修复的同时发布安全公告。其他漏洞则保留现有的披露时间表。此次政策变更并未宣布任何特定的新漏洞，而 AI 生成的报告并不自动就是真实漏洞。这一变更涉及的是从经确认的发现、到修补后的发布、再到公开详细信息之间的时间。

比特币节点在本地验证区块和交易，交易所、托管机构和其他服务都围绕它们构建运营。一次发布可能会让修补后的软件在所有受支持的版本上可用，但这些系统的运营者决定何时安装它。Bitcoin Core 并不会在每台机器上自我更新。公开披露可以帮助人们识别问题并安装修复，同时也会给攻击者提供信息，使其知道未修补的节点仍可能通过其网络行为泄露什么。

新政策将发现难度与严重性分开

Bitcoin Core 此前已根据漏洞的影响及其可能被利用的方式，将其分类为严重、高、中或低。在默认设置下可远程触发的崩溃可能属于高严重性；需要非标准配置或仅造成有限破坏的漏洞可能被归为较低级别。修订后的安全公告政策增加了一个单独的问题，即某人发现该问题的难易程度。其示例是向大型语言模型输入一个简单的提示词，但该类别并不限于使用 AI 发现的漏洞。

这一区分避免了常见的误读。“容易被发现”并不意味着“低严重性”。一个漏洞可能很容易找到，且对受影响的节点具有危险性。反过来，一个隐蔽的问题如果被利用，可能产生严重影响，但仍值得在细节公开之前留出更多时间。维护者在分诊期间评估报告，并选择是否适用快速途径。已发布的政策给出了标准和计划中的响应，但并未公布一个机械化的阈值来决定哪些提示词、工具或技能算作“极少的努力”。

提出该网站变更的 Antoine Poinsot 在拉取请求讨论中表示，维护者收到了更多关于容易被重新发现的漏洞的报告。他将这一变化很大程度上归因于语言模型降低了发现某些问题或找出开发者试图保密的修复所需的努力。在他看来，当另一个人能够迅速独立地发现该弱点时，隐瞒细节所提供的保护就更少。同样的禁令也可能延迟那些仍停留在受支持的旧分支上的运营者获得已修复的版本。

对于归入新类别的报告，Bitcoin Core 表示，它将针对每个受维护的主版本发布包含修复的点版本，并同时发布一份安全公告。“尽快”描述的是一种意图，而不是从首次报告起固定的若干小时数。开发者仍需确认问题、编写并审查补丁、在每个分支上进行测试并准备发布。该政策并不承诺未受维护的版本会获得补丁，也不承诺所有运营者都会在公告发布前完成升级。

较旧的禁运期可能跨越多个版本

普通披露遵循不同的时间表。该政策规定，低严重性漏洞在包含修复的主版本发布两周后披露。中、高严重性问题在最后一个受影响版本到达生命周期终点后披露，大约是在某个主版本首次包含修复的一年后。维护者在公开被禁运问题前两周发布预告，说明修复了多少个漏洞及其严重性级别。严重缺陷不在该标准时间表之内，需要针对事件量身定制的响应。

32.0 版本发布说明给出了一个具体对比。说明称，在 30.0 版本中修复的三个中或高严重性漏洞将在较新版本发布两周后披露，而 32.0 中没有按该时间表需要披露的低严重性漏洞。在 Bitcoin Core 的生命周期表中，30.0 版本的日期为 2025 年 10 月 10 日。32.0 版本的发布时间表记录其标签日期为 2026 年 10 月 21 日。这两个日期相隔 376 天，这是对较早修复日期与较新标签日期的算术比较，而不是项目宣布的单个公告日期。

发布说明没有指明这三个缺陷的组件或利用条件。按照标准流程，修复可以在较新版本中保持可用，而详细信息则保持私密，直到较旧的受影响分支离开维护窗口。新的路径只改变维护者判断为容易被发现的漏洞的考量。它并不会取消较难发现的中、高严重性案例的漫长 timetable。

过去的一次披露展示了旧路径的实际运作。Bitcoin Core 于 2026 年 5 月披露了 CVE-2024-52911，而该缺陷已在 2025 年 4 月发布的 29.0 版本中修复。一个特制的区块可能触发脚本解释器中的释放后使用条件，并使易受攻击的节点崩溃。生成具有足够工作量证明的区块使攻击成本高昂，项目认为远程代码执行不太可能。修复与公开细节之间的间隔是先前披露方法的一部分；这并不能证明旧问题会符合当今的易发现标准。

三个受维护版本决定了谁能获得修复

Bitcoin Core 的软件生命周期规定，维护者支持最新的三个主版本。当新的主版本发布时，三者中最旧的版本到达生命周期终点，通常不再接收安全修复。随着 32.0 版本于 10 月 21 日打上标签，且其发布说明称 29.x 及更旧版本已到达生命周期终点，新快速路径对应的分支为 30.x、31.x 和 32.x。为这些分支各发布一个点版本，可以让使用 30.x 的运营者应用针对性补丁，而不必立即采纳 32.0 中的每一项功能和行为变更。

32.0 候选发布周期于 9 月 14 日开始，项目于 10 月 21 日打上稳定版标签。发布标签、二进制文件和已安装节点之间的区别很重要。时间表显示的是 32.0 标签；官方分发和运营者自身的部署是后续步骤。在准备本专题时，其生命周期页面仍显示 32.x 的发布日期为“TBA”，尽管发布时间表已显示该标签。32.0 发布说明称 29.x 及更旧版本已到达生命周期终点。Bitcoin Core 尚未更新其生命周期表上显示的 32.x 日期。

仍受支持的分支并不会自动获得补丁。该政策称修复将被向后移植到每个受维护的主版本，而生命周期页面称向后移植的门槛通常随着分支变旧而提高。新的易发现承诺对其涵盖的安全漏洞更为具体。维护三条已打补丁的代码线需要在代码差异之间进行审查和测试，而不是简单地将一个提交复制到三个目录中。一个能干净地应用于某个分支的修复，在另一个分支上可能需要不同的工作。Bitcoin Core 尚未为此项工作指定固定时限。

三个分支之外的运营者面临不同的决定。29.x 版本在生命周期结束后可能仍能启动并验证普通区块，但通常不会收到新的安全点版本。运行该版本的运营者必须迁移到受维护的分支，才能获得未来的补丁。Bitcoin Core 建议采用运营者所能采用的最新主版本的最新维护版本。拥有自定义集成或钱包数据的企业在迁移前可能需要自行进行兼容性检查。生命周期结束描述的是项目的支持边界，而不是在某个特定日期关闭旧软件的开关。

Bitcoin Core 的生命周期页面还做出了另一个区分，这一点在安全警报中容易被忽略。主版本是一个分支，而次版本是该分支上的维护更新。运行 30.0 的人和运行 30.3 的人都在 30.x 上，但他们不一定安装了相同的修复。如果项目针对一个容易发现的漏洞发布新的 30.x 点版本，仅仅报告某个服务运行的是“版本 30”并不能确立其受到保护。需要完整的版本号和该版本的修复列表。这就是为什么一家公司声称已升级其节点却没有说明所部署的构建版本，会让核心问题悬而未决。

32.0 版本的发布说明描述了正常升级如何从关闭旧软件开始，等待其完成后再安装替代版本。拥有交易索引、钱包或连接应用程序的节点运营者可能需要执行额外的检查。项目文档称，维护版本通常避免引入重大的新功能，这使得打补丁的点版本比跳转到新的主分支范围更窄。每次部署仍然必须针对其周围的软件进行测试。

补丁可能在大多数节点安装之前就已公开

Bitcoin Core 没有能够向每个节点推送更新的中央运营者。运行家庭节点的个人可能在看到公告后不久就下载发布版本。托管机构或交易所可能在更改生产节点之前，针对内部服务、钱包系统和监控测试升级。矿池有另一套验证和区块构建依赖关系。这些是运营上的可能性，而不是对每个群体安装任何特定 Bitcoin Core 更新速度的实测列表；政策变更并未附带采用数量。

公开公告改变了双方可获得的信息。它可以描述受影响的版本、影响和修复，以便运营者采取行动。它也可能为测试旧节点是否存在相同弱点的人提供线索。Poinsot 的论点是，攻击者可能在没有公告的情况下就已经发现一个容易发现的缺陷，而如果修复的点版本被推迟到后来的主版本才发布，运营者打补丁的机会就更小。这一立场是加速修复的理由，而不是一旦发布上线暴露就会消失的证据。

分发方式与通知同样重要。节点运营者需要获取正确的二进制文件或源代码包，按照项目的发布流程检查其真实性，安全地停止当前软件，并在适合部署的版本上重新启动。社交媒体上的警告不能替代签名的发布版本和官方公告。Bitcoin Core 的 32 版本说明告诉用户在安装新软件之前关闭旧版本并等待其完成。这些步骤平淡无奇，但如果服务依赖关系尚未就绪，匆忙的生产变更可能会引入自身的停机。

自动监控可以帮助组织注意到发布。它无法决定其运行的节点是否受到依赖于特定功能或配置的漏洞的影响。公告应提供足够的细节，以便对相关系统进行优先级排序。在发布和部署之间的间隔期内，面向网络的节点仍然是一个实际问题。该项目尚未公布运营者安装维护版本的实测中位时间，因此截至 10 月 24 日，标题中的问题无法用全网数字来回答。

AI 报告在任何公开警报之前需要验证

Bitcoin Red Team 提供了一个引人注目的例子，说明 AI 辅助审查可以产生的规模。8 月，crypto.news 报道了 4,962 个潜在问题，涉及 390 个比特币相关项目，这是该小组在审查的前 29.8 小时内发现的。该小组将 720 个归类为高或严重，并表示截至报告日期，超过五分之一的潜在发现已被复现。这些是该小组针对一系列项目的数字，而不是 Bitcoin Core 漏洞的数量，也不是经过验证的可利用漏洞统计。

生成的发现与已确认的缺陷之间的区别是新政策的核心。模型可以提示一条穿过代码的路径，但维护者必须复现它，确定攻击者是否能够到达该路径，并确定哪些版本受到影响。测试框架中的发现可能并不存在于生产环境中；一个代码分支中缺失的检查可能在别处有补偿性控制。严重性需要考察真实的先决条件和后果。快速披露分类是在那项技术工作之后进行的，而不是在 AI 工具打印出一个看似合理的解释时。

项目仓库将代码审查和测试描述为开发的瓶颈。大量低质量报告可能会消耗修复严重问题所需的同样稀缺的注意力。反过来，一份可信、可复现的报告可以给维护者更早的警告。Bitcoin Core 的安全报告说明将敏感发现引导至其安全电子邮件地址，而不是公开问题。该更新并没有使在维护者仍在检查时公开张贴未经证实的漏洞利用细节成为一种稳妥做法。

比特币安全组织在八月请求获得前沿 AI 访问权限，以支持防御性工作。Bitcoin Core 的单独政策变更针对的是同一工具的其他用户可能重新发现的缺陷。Poinsot 表示，维护者已收到更多此类报告，并得出结论：在这些情况下，隐瞒修复所提供的保护微乎其微。

安全政策的四个严重性示例说明了为什么一个警告不能适用于每个节点。在默认设置下远程触发的崩溃可以中断一个公开连接的服务。需要在本地网络上启用特殊功能的缺陷影响较小的群体。区块模板构建中的问题对矿工可能很紧急，但对仅验证传入区块的商户节点不会产生同样的即时行动。在每种情况下，“易于重新发现”衡量的是攻击者了解该弱点的容易程度，而不是哪些运营者拥有受影响的配置。如果新的时间表要有用，公告必须同时包含这两部分信息。

Bitcoin Core 的历史公告列表包括减缓区块传播、耗尽内存或使节点崩溃的拒绝服务状况，以及过去威胁共识的通货膨胀漏洞。这些不是可互换的事件类别。该政策明确将严重缺陷排除在标准时间表之外，为围绕整个网络风险制定的响应保留了空间。因此，新的易于发现路径应被解读为项目安全流程内的一项新增披露决定，而不是声称 AI 改变了比特币的共识规则。

开发者对警告本身存在分歧

政策讨论包括对同时发布和公开警告的实质性反对意见。比特币开发者 Antoine Riard 在拉取请求中辩称，公告可能会在未受特定漏洞影响的用户中引发不必要的仓促迁移。他的示例将矿工需要紧急处理的区块模板问题与商户可以采取更谨慎升级路径的情况区分开来。不加区分的安全警报会让每个运营者都觉得必须立即更改生产系统。

Riard 并未质疑某些漏洞易于发现。他质疑的是向面临不同风险水平的运营者发送警报的时机和内容。快速发布可以同时为矿工、商户、钱包和交易所提供一个修补分支，而公告则解释每个群体的不同暴露情况。如果公告过于模糊，受影响的运营者可能认识不到其紧迫性；如果过于宽泛，未受影响的运营者可能采取破坏性行动。最终政策保留了在点版本发布的同时提供公告的承诺，但未指定用于描述每个受影响角色的单一模板。

Poinsot 的反驳理由是，更长的保密期可能使受支持的旧分支无法获得修复，而一个容易被发现的漏洞不太可能仅仅因为项目等待就保持隐藏。双方立场都承认部署缓慢且公开通知可以改变行为。他们的分歧在于对于某个特定已确认缺陷，哪种风险占主导。该政策将“易于发现”作为一项分诊判断，让维护者仅在认为补丁延迟比披露风险更难辩解时才选择快速路径。

两种论点都没有确立公开总是无害的，或保密总是保护人们。一个影响默认网络服务的非常简单的缺陷可能使速度至关重要。一个影响狭窄、非默认设置的缺陷即使模型可以轻松描述，也可能值得高度具体的说明。严重性类别和新的发现评估应共同塑造发布说明。Bitcoin Core 尚未公布未来案例的名单，也尚无变更后的事件确立该方法在实践中的效果如何。

Core Lightning 提供了一个不同的运营范例

Bitcoin Core 的政策管辖的是 Bitcoin Core，而非比特币生态系统中的每一个程序。Core Lightning 的开发者们在八月份也面临了他们自己的人工智能生成报告数量问题，并确认其中几份提交描述了真实的缺陷。十月份，该团队警告旧版本节点的运营者，此前有报告称运行 26.06.7 或更早版本的系统遭到了攻击。团队敦促升级到更新的版本。在该警告中，团队并未公开确认攻击方法或确认用户损失，因此这些报告不应被视为特定漏洞利用的证据，也不应套用到 Bitcoin Core 的代码上。

Lightning 的例子说明了为什么有可用的修复程序并不等于完成了安全响应。在补丁版本发布后，运营者可能仍继续使用旧软件。其 8 月 26.06.7 版本的源代码最初被扣留了两周，以便运营者能在潜在攻击者研究变更之前安装该版本；随后源代码的发布和十月份的警告遵循了与 Bitcoin Core 新的易于发现途径不同的披露顺序。软件、网络层和威胁各不相同。共同的实际情况是，只有当相关运营者理解通知并部署正确的更新时，通知才能保护系统。

一些 Lightning 节点运营者被告知，在继续监控区块链的同时，离线运行守护进程可以暂时限制暴露风险。Bitcoin Core 的运营者不应在未检查自身应用程序要求的情况下照搬该指示。钱包、交易所或 Lightning 服务所使用的全节点可能承担着即使网络连接发生变化也仍需继续履行的义务。针对特定缺陷的 Bitcoin Core 公告将需要说明临时配置更改是否有用。10 月 22 日的政策中并未出现任何一刀切的变通方案。

当缺陷并不影响所有设置时，“可用”与“已安装”之间的差异最容易显现。矿工可能会在其验证节点旁运行区块模板服务。托管平台可能会将其 Bitcoin Core 进程与公共互联网隔离，但允许内部程序调用其 RPC 接口。家庭用户可能会使用带有内置钱包的默认网络设置。一个点版本可以修复所有这三种部署，但即时暴露风险和测试更新所需的时间可能不同。Bitcoin Core 的公开政策并不试图为这些运营者设定一个统一的截止日期。

一份范围明确的公告可以说明受影响的版本和设置、成功利用可能造成的损害，以及攻击是否需要网络访问、本地访问或特定的用户操作。该项目在过去的公告类别中曾使用过这些区分。运营者随后可以将自己的配置与所述条件进行比较。10 月 22 日的修正案承诺发布一份包含针对易于发现类别的修复的公告，但所披露的确切事实将取决于第一个被如此分类的已验证问题。

首次快速披露将确立节奏

书面变更给了维护者一条新途径，但尚未提供案例研究。可衡量的顺序始于一份已验证的报告和分类，接着是为所有三个维护分支提供补丁，最后是签名的点版本和一份公告。这些步骤的日期将显示该项目能多快地将修复向后移植，以及其公开通知是否仅在每个分支都准备就绪时才到达。一个仅覆盖三个维护线中两个的版本将不符合新类别所公布的承诺。

运营者的采用情况更难观察。可公开访问的节点可能会公布软件版本，但网络爬虫只能看到部署的一个子集，而且版本字符串不一定披露每一个私有服务。交易所和托管机构可能使用从不接受入站公共连接的内部节点。报告升级百分比的研究人员应解释样本及其盲点。否则，该数字可能低估仍暴露的生产基础设施份额，或通过计入休眠的公共节点而高估它。

32.0 版本的说明指引运营者前往该项目的公告列表以获取安全和更新通知。其生命周期页面建议使用运营者所能使用的最新主分支的最新维护版本。下一次禁运披露预计在 32.0 版本发布两周后进行，并将描述已在 30.0 中修复的三个中危或高危漏洞。

值得关注的内容

• 首个被分类的案例：一份公告，说明一个易于发现的缺陷、其受影响的版本以及快速发布修复的依据。
• 三个点版本：针对 30.x、31.x 和 32.x 的相应修复，或者如果出现新的主版本，则更新维护边界。
• 公告细节：当矿工、商户、托管方和家庭节点的实际暴露情况不同时，明确区分它们。
• 运营者采用情况：带有明确样本的按日期统计的版本测量数据，以及运行私有节点的服务所披露的信息。
• 待处理的旧案例：30.0 中的三个中危或高危修复，32.0 的发布说明称将在通常的延迟之后予以解释。

常见问题