Bitcoin Core 已修改其安全披露政策，因为开发者发现，一些漏洞只需很少的努力就可能被重新发现，包括向 AI 模型发出一个简单提示。

• Bitcoin Core 于10月22日合并了修订后的安全政策，为那些容易被重新发现的缺陷增加了快速披露路径。
• 新路径承诺：对三个仍在维护的主要版本分别发布修复补丁，并同步发布公开安全公告。
• 其他低严重性漏洞仍按主要版本发布后两周披露；中高严重性漏洞则可能等待更久。
• 32.0版本说明列出了三个在30.0版本中修复的中高严重性漏洞，其细节将在较新的版本发布后再披露。
• Bitcoin Core 于10月21日标记32.0版本，30.x、31.x和32.x都处于其三个版本的维护窗口内。

该项目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天，这只是对旧修复日期与新标记日期的算术比较，并不是项目对某个单独公告所给出的发布日期。

说明并未标明这三个漏洞的组件或利用条件。按照标准流程，一个修复可以先在较新的版本中可用，而细节仍保持私密，直到受影响的旧分支退出维护窗口。新路径只会改变那些维护者判断为“容易被发现”的漏洞的处理方式，并不会取消那些更难发现的中高严重性问题的长期时间表。

过去的一次披露展示了旧路径的实际运作。Bitcoin Core 在2026年5月披露了 CVE-2024-52911，而该漏洞早已在2025年4月发布的29.0版本中修复。一个特制区块可以触发脚本解释器中的 use-after-free 条件，并导致受影响节点崩溃。生成一个具有足够工作量证明的区块会让攻击成本很高，项目也认为远程代码执行不太可能。修复与公开细节之间的间隔，是此前披露方式的一部分；这并不能证明旧问题在今天会符合“容易发现”的标准。

三个受维护版本决定谁能拿到修复

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.0版本说明提醒用户：在安装新软件前，先关闭旧版本并等待其完全结束。步骤看似平常，但如果服务依赖没有准备好，仓促的生产环境变更也可能引发自己的故障。

自动监控可以帮助机构注意到某个版本发布，但它无法判断正在运行的节点是否受某个依赖特定功能或配置的漏洞影响。公告应提供足够细节，以便优先处理相关系统。在公告发布到部署之间的这段时间里，面向网络的节点仍然是现实中的关注点。项目并未公布运营者安装维护性更新的中位时间，因此截至10月24日，标题中的问题无法用一个全网数字来回答。

AI 报告在公开警报前仍需验证

Bitcoin Red Team 提供了一个引人注目的例子，说明 AI 辅助审查可能产生多大的规模。crypto.news 在8月报道称，该团队在最初29.8小时的审查中，跨390个比特币相关项目发现了4,962个潜在问题。其中720个被归类为高或关键级别，且截至报告日期，超过五分之一的潜在发现已被复现。这些数字是该团队针对一系列项目给出的统计，并不是 Bitcoin Core 漏洞数量，也不是可利用漏洞的已验证总数。

生成的发现与确认的漏洞之间的差别，是新政策的核心。模型可以提示一条代码路径，但维护者必须复现它，确认攻击者是否能够触达，并判断哪些版本受影响。测试环境中的发现未必存在于生产环境；某个代码分支中的缺失检查，可能在别处有补偿性控制。严重性需要结合真实前提和后果来判断。快速披露分类是在这些技术工作完成之后才会发生，而不是在 AI 工具打印出一个看似合理的解释时就成立。

项目仓库把代码审查和测试描述为开发瓶颈。大量低质量报告可能会消耗同样稀缺的注意力，而这些注意力本应用于修复严重问题。反过来，一个可信且可复现的报告，也能更早提醒维护者。Bitcoin Core 的安全报告说明要求将敏感发现发送到其安全邮箱，而不是公开提交 issue。此次更新并不意味着在维护者仍在核查时，就公开发布未经验证的利用细节是好做法。

比特币安全团队在8月请求使用前沿 AI，以支持防御工作。Bitcoin Core 的这项独立政策变化，针对的是其他使用同类工具的人也可能重新发现的漏洞。Poinsot 表示，维护者收到了更多此类报告，并得出结论：在这些情况下，继续隐瞒修复并不能提供多少保护。

安全政策中的四个严重性示例说明了为什么一条警告无法适用于所有节点。一个在默认网络服务上可远程触发的崩溃，可能会干扰一个公开连接的服务；一个需要在本地网络启用特殊功能的漏洞，只会影响更小的群体；一个出现在区块模板构建中的问题，对矿工来说可能很紧急，但对只验证传入区块的商家节点而言，未必需要同样立即行动。每种情况下，“容易重新发现”衡量的是攻击者多容易了解这个弱点，而不是哪些运营者拥有受影响的配置。若新时间表要真正有用，公告必须同时包含这两类信息。

Bitcoin Core 历史上的公告列表包括拒绝服务条件、内存耗尽或节点崩溃等问题，也包括曾威胁共识的通胀漏洞。这些并不是可互换的事件类别。政策明确把关键漏洞排除在标准时间表之外，为围绕整个网络风险的响应保留空间。因此，这条新的“容易发现”路径应被理解为项目安全流程中的一个额外披露决策，而不是 AI 改变了比特币共识规则。

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

政策讨论中有一项重要反对意见，针对的是“同时发布修复和公开警告”。比特币开发者 Antoine Riard 在拉取请求中表示，公告可能会让那些并不受该漏洞影响的用户，产生不必要的仓促迁移。他举例区分了一个矿工需要紧急处理的区块模板问题，以及一种商家可以更谨慎升级的情况。没有区分的安全警报，可能让每个运营者都觉得自己必须立刻更改生产系统。

Riard 并不否认某些漏洞很容易被发现。他质疑的是：向面临不同风险水平的运营者发送警报时，时机和内容应该如何安排。快速发布可以让矿工、商家、钱包和交易所同时拿到修补分支，而公告则解释各群体面临的不同暴露。如果公告过于笼统，受影响的运营者可能意识不到紧迫性；如果范围过宽，未受影响者可能采取破坏性行动。最终政策保留了与小版本更新同步发布公告的承诺，但没有为描述每个受影响角色设定统一模板。

Poinsot 的相反观点是，更长时间的保密会让仍受支持的旧分支迟迟得不到修复，而一个很容易被发现的漏洞，不会因为项目等待而真正隐藏起来。双方都承认部署很慢，公开通知会改变行为；分歧在于，对某个已确认漏洞而言，哪种风险更占主导。政策把“容易发现”设为一个分诊判断，只在维护者认为“延迟补丁”比“披露风险”更难以辩护时，才选择快速路径。

这两种观点都不能证明公开总是无害，也不能证明保密总能保护人们。一个影响默认网络服务、且非常简单的漏洞，可能让速度成为首要任务；一个只影响狭窄、非默认配置的漏洞，即便模型能轻易描述，也可能需要非常具体的说明。严重性类别和新的发现评估应共同决定发布说明。Bitcoin Core 尚未公布未来案例清单，而政策变化后也还没有任何事件能证明这一方法在实战中的效果。

Core Lightning 提供了不同的运营样本

Bitcoin Core 的政策只约束 Bitcoin Core，并不适用于比特币生态中的所有程序。Core Lightning 开发者在8月也面对大量 AI 生成报告，并确认其中若干条确实描述了真实漏洞。10月，团队在收到针对运行26.06.7或更早版本系统的攻击报告后，提醒旧节点运营者尽快升级到更新版本。团队当时并未公开确认攻击方法，也未确认用户损失，因此这些报告不应被视为某个特定利用方式的证据，也不能直接套用于 Bitcoin Core 的代码。

Lightning 的例子说明：即便修复已经可用，安全响应也并未完成。运营者在修补版本存在后，仍可能继续使用旧软件。其8月26.06.7源码最初被延后公开两周，以便运营者先安装版本，再让潜在攻击者研究变更；随后源码公开和10月警告遵循了与 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的修复，或在新主要版本到来时更新维护边界。
• 公告细节：当矿工、商家、托管机构和家庭节点的实际暴露不同，公告应清楚区分。
• 运营者采用情况：带有明确样本的版本测量，以及运行私有节点服务的披露。
• 待披露的旧案例：32.0版本说明提到的、来自30.0版本的三个中高严重性修复，将在通常延迟后解释。

常见问题

2026年10月 Bitcoin Core 的安全政策发生了什么变化？

10月22日合并的一项变更允许维护者在为每个仍在维护的主要版本发布修复时，对容易被重新发现的漏洞同步发布安全公告。其他情况仍沿用基于严重性的常规封锁期。

这项新政策是否意味着 Bitcoin Core 今天出现了新漏洞？

政策修订并未宣布任何具体漏洞。它改变的是：未来一份已确认报告如何被分类和披露。

什么算是容易被发现的 Bitcoin Core 漏洞？

政策指的是那些只需很少努力就能找到的问题，包括通过简单的 AI 提示发现的情况。该标准并不局限于 AI，且由维护者在分诊时决定，而不是套用一个公开的数值测试。

有多少个 Bitcoin Core 版本会获得更快修复？

Bitcoin Core 维护最新的三个主要版本。随着32.0发布，相关分支是30.x、31.x和32.x；29.x及更早版本已超出维护窗口。

所有 Bitcoin Core 漏洞都会立即披露吗？

不会。低严重性问题通常在包含修复的主要版本发布两周后披露；中高严重性细节可能要等到最后一个受影响分支到达生命周期终点两周后才公开；关键漏洞则需要单独响应。

为什么公开公告会带来风险？

它能帮助运营者识别受影响的软件，但也可能在部分节点仍运行旧版本时，给攻击者提供线索。比特币开发者 Antoine Riard 警告称，一条笼统的警报可能会让不同暴露程度的用户产生不必要的仓促升级。

AI 生成的漏洞报告都是真的吗？

不是。Bitcoin Red Team 的4,962个潜在发现横跨390个项目，且都需要复现和审查。这些数字并不是 Bitcoin Core 已确认漏洞的数量。

我们什么时候会知道运营者能否及时更新？

快速路径下的首个公告将展示发布日期、受影响分支和操作说明。公开节点测量可以显示部分采用情况，但私有部署可能不会被纳入。本文仅供信息和教育用途，不构成投资建议。