Bitcoin Core 更新安全披露政策：可被簡單大語言模型提示輕易發現的漏洞，將盡快為所有仍維護的主要版本推出修補點更新並同步發布安全公告，不再套用按嚴重程度而定的標準禁運期；其餘漏洞仍按低／中／高嚴重度時間表披露，臨界級則另行處理。政策已刊於官方 Security Advisories 頁，並以「easily discoverable」分類明確點出 LLM 提示即可發現的案例。

Bitcoin Core／官方：更新漏洞披露政策——「易發現」含簡單 LLM 提示；將盡快修補各維護主版本並同步公告

Bitcoin Core 在官方 Security Advisories 政策頁更新漏洞披露規則，新增「easily discoverable」（易發現）分類：若漏洞只需極少工夫即可發現——官方舉例包括透過簡單的大語言模型（LLM）提示——團隊會盡快為每個仍在維護的主要版本發布含修復的點更新（point release），並同步刊出安全公告，不再套用原先按嚴重程度而定的標準禁運期。本文已核對 bitcoincore.org 政策全文，並以 Cointelegraph 二零二六年十月二十三日報道作發現來源交叉核對，來源真實性已驗證；下文只採納可核對的政策條文與報道中已指明的公開表述，不外推未公布的漏洞清單或時程。

一、核心事件：AI 易復現漏洞，令「長禁運」失去保護作用

政策條文（一手）

官方政策先把漏洞分為四級：Critical（臨界）、High（高）、Medium（中）、Low（低），並以是否危及整個比特幣網絡的根本安全與完整性、遠端可利用性、影響範圍等作為分級示例基礎（例如協議層盜幣／超額發行／永久性全網分叉屬臨界；預設配置下可遠端令大量節點離線屬高等）。

在披露時間表上，關鍵新增是：公開披露時間線取決於該漏洞是否被歸類為 easily discoverable。官方寫明，此分類適用於「只需極少工夫即可發現」的漏洞，例如透過簡單 LLM 提示。對這類漏洞，團隊會：

盡快為每個仍維護的主要版本發布含修復的 point release；
同時發布 security advisory；
不套用標準、按嚴重程度而定的禁運期。

其餘（非「易發現」）漏洞則沿用嚴重度時間表：

Low：在含修復的主要版本發布後兩星期披露；
Medium／High：在最後一個受影響版本進入 End of Life 後兩星期披露（官方註：大約在含修復的主要版本首次發布約一年後）；
禁運漏洞細節發布前兩星期會有預告，並與新主要版本發布同期，內容含已修復漏洞數量與嚴重度；
Critical 不納入上述標準流程，多數需 ad-hoc 程序；個別問題亦可能被判定為「嚴重但無需禁運」，或根本不構成 vulnerability。

通報渠道維持 [email protected]（詳見倉庫 SECURITY.md）。

報道脈絡（二手、標明出處）

Cointelegraph 於二零二六年十月二十三日報道稱，開發者 Antoine Poinsot 同日（報道所稱星期四）向 Bitcoin Development Mailing List 說明：過去長禁運有助用戶升級，但亦令修復難以及時回移植到舊版；在 LLM 令部分缺陷極易被重新發現的背景下，「禁運期幾乎起不到保護作用，反而拖延修復版本上線」，因此更新披露政策。報道並引述政策中「簡單 LLM 提示」的分類表述，以及 Red Team／Core Lightning 等生態在 AI 輔助漏洞報告壓力下的近期背景。本文不以郵件列表原文作唯一依據，核心規範仍以官方政策頁為準。

二、技術原理：禁運、回移植與「可複現性」改變了攻防節奏

傳統協調披露假設是：細節保密一段時間 → 維護者推出修復 → 用戶升級 → 再公開細節，以縮短「細節已知但修補未普及」的窗口。對比特幣全節點軟體而言，禁運往往與主要版本節奏綁在一起：若修復不能或不便回移植（backport）到仍有大量運營者在跑的舊主版本，長禁運等於延長這批節點的暴露面。

LLM 輔助審計改變的是「保密能否買到時間」。若缺陷可用極低成本反覆發現，攻擊者與善意研究者都能快速獨立復現，則禁運對攻擊者的阻力下降，對用戶的代價（遲遲拿不到舊版修補）反而上升。Bitcoin Core 以「easily discoverable」把這類問題從標準禁運表拆出，改為：多主版本同步點更新 + 同步公告，等於用「快修、廣修、早說」取代「慢說、等大版本」。

這並非取消分級：臨界級仍走專案程序；中高嚴重度在非易發現情況下仍可有較長的 End of Life 相關披露節奏；預告機制亦保留給仍受禁運的項目。重點是承認「發現成本」已成為與 CVSS 式嚴重度平行的披露變量。

三、日常應用場景

1. 開發者與技術團隊

運行 bitcoind／相關分支或依賴 Bitcoin Core 組件的團隊，應把「easily discoverable」政策寫進漏洞應變 Runbook：訂閱官方 Security Advisories 與主要版本發布說明；對仍在維護窗口內的主版本，預期可能出現更頻密的 point release，而不是只等下一個大版本。內部若以 LLM 做靜態／模糊測試，發現疑似問題應經 security@ 渠道通報，勿先在公開庫開 issue 貼可利用細節。

2. 企業與隱私敏感行業

託管節點、支付網關、託管錢包基礎設施與合規審計團隊，需更新補丁 SLA：過去可假設「中高危細節會長時間保密」，現在對 AI 易挖出的類別，公開與修補可能幾乎同步。變更管理應允許在短窗口內升級多個仍支援的主版本，並驗證監控／告警不會因點更新配置差異而漏報。

3. 一般用戶

自行運行全節點或常用依賴 Core 的錢包後端的用戶，應開啟官方發布與安全公告追蹤，並優先使用仍在支援生命週期內的版本；政策本身不要求一般持幣者操作鏈上資產，但節點營運者的升級紀律會間接影響自身連線穩定性與對異常對等節點的暴露。

4. 香港與亞洲市場視角

香港虛擬資產服務提供者、銀行創新部門與企業財資若自營或委託運營比特幣基礎設施，需把「AI 輔助漏洞發現」納入第三方風險與補丁管理條款：要求供應商說明所跟主版本、點更新套用時限，以及是否監控 bitcoincore.org 安全政策變更。亞洲時區與歐美發布窗口錯開時，更應以自動化檢查與值班制度縮短「公告已出、本地未升級」的空窗——這與雲端工作負載的緊急修補文化一致。

四、專業評價與潛在考量

優勢

官方以成文政策明確引入 LLM／低成本發現作為披露變量，減少「是否該提早公開」的個案爭議空間。
「各維護主版本盡快 point release + 同步 advisory」直接對準舊版用戶長期裸奔的痛點。
保留 Critical ad-hoc、以及中高危在非易發現情況下的 EOL 相關節奏，避免一刀切把所有問題都即時公開。

需要留意的地方

「easily discoverable」仍屬判斷分類，邊界案例（例如需複雜鏈上條件才觸發、但提示工程可加速定位）可能引發社群討論。
更頻密的點更新會提高營運者的升級與回歸測試負擔；若組織只釘死單一舊大版本且不跟點更新，政策好意無法自動覆蓋。
Cointelegraph 對郵件列表動機的引述有助理解背景，但合規與工程決策仍應以 bitcoincore.org 現行政策頁與實際 advisory／版本發行記錄為準。

結語

Bitcoin Core 今次政策調整，本質是承認：當部分軟體缺陷的發現成本被大語言模型壓低，「長禁運換升級時間」的古典假設對這子集不再成立。官方改以「易發現 → 多主版本快修並同步公告」回應，同時保留嚴重度分級與臨界級專案程序。對香港與亞洲的節點營運者、Web3 基礎設施與雲端安全團隊而言，啟示是把 AI 輔助審計視為會改變披露時鐘的結構因素，而不是偶發噪音——補丁窗口、版本支援矩陣與安全公告訂閱，都應按此重算。

若貴公司正在加固節點／鏈上相關基礎設施、雲端遷移或弱點應變流程，可參考 YSK Limited 的雲端遷移與網絡安全服務（https://ysk.hk/services/cloud-security），涵蓋零信任架構、高可用部署與官網所述百分之九十九點九九服務在線率（SLA）目標；Web3 智能合約與節點營運需求亦可見 https://ysk.hk/services/web3-blockchain。

參考來源

Bitcoin Core 官方 Security Advisories 政策頁（含 easily discoverable／LLM prompt 分類與披露時間表）https://bitcoincore.org/en/security-advisories/
bitcoin/bitcoin 倉庫 SECURITY.md（通報郵箱與支援版本指引）https://github.com/bitcoin/bitcoin/security/policy
Cointelegraph：Bitcoin Core changes security policy as AI makes bugs easier to find（2026-10-23）https://cointelegraph.com/news/bitcoin-core-changes-security-policy-as-ai-makes-bugs-easier-to-find
YSK Limited 雲端遷移與網絡安全 https://ysk.hk/services/cloud-security
YSK Limited Web3 區塊鏈開發 https://ysk.hk/services/web3-blockchain