Bitcoin Core 將提前公開部分漏洞，節點營運者能及時更新嗎？

Bitcoin Core 在開發者發現某些漏洞只需極少心力即可被重新發現（包括對 AI 模型下一個簡單提示）之後，更改了其安全披露政策。

該專案的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 版本中修復。一個特製的區塊可能觸發腳本解釋器中的釋放後使用條件，並使易受攻擊的節點崩潰。產生具有足夠工作量證明的區塊使攻擊成本高昂，該專案認為遠端程式碼執行不太可能。修復與公開細節之間的差距是先前披露方法的一部分；這並不能證明該舊問題會符合當今的易於發現標準。

三個維護版本定義了誰能獲得修復

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 的開發者在八月也面臨了自身由 AI 生成的報告量，並確認其中數份提交描述了真實的缺陷。十月，該團隊在接獲針對執行 26.06.7 或更早版本系統的攻擊報告後，警告較舊節點的營運者。它敦促升級至較新的版本。該團隊在該警告中並未公開識別出攻擊方法，也未確認使用者損失，因此這些報告不應被視為特定漏洞利用的證據，也不應套用於 Bitcoin Core 的程式碼。

Lightning 的例子說明了為何有可用的修補程式並不能完成安全回應。在修補版本存在之後，營運者仍可能繼續使用較舊的軟體。其八月 26.06.7 的原始碼最初被保留了兩週，以便營運者能在潛在攻擊者研究變更之前安裝該版本；隨後原始碼的發布與十月的警告，遵循了與 Bitcoin Core 新的易於發現途徑不同的揭露順序。軟體、網路層與威脅各不相同。共同的實務事實是，通知只有在相關營運者理解它並部署正確的更新時，才能保護系統。

部分 Lightning 節點營運者被告知，在持續監控區塊鏈的同時，離線執行守護程式可暫時限制暴露風險。Bitcoin Core 的營運者不應在未檢查自身應用程式需求的情況下照搬該指示。由錢包、交易所或 Lightning 服務使用的完整節點，可能負有即使網路連線改變仍持續存在的義務。針對特定缺陷的 Bitcoin Core 公告將需要說明暫時的配置變更是否有用。十月二十二日的政策中並未出現任何一體適用的變通方案。

當缺陷並非影響每一種設定時，「可用」與「已安裝」之間的差異最容易看出。礦工可能會在其驗證節點旁執行區塊範本服務。託管平台可能會將其 Bitcoin Core 程序與公開網際網路隔離，但允許內部程式呼叫其 RPC 介面。家庭使用者可能會以內建錢包執行預設網路設定。一個單點版本即可修復這三種部署，然而立即的暴露風險與測試更新所需的時間可能不同。Bitcoin Core 的公開政策並未試圖為這些營運者指定一個通用的期限。

一份範圍界定良好的公告可以說明受影響的版本與設定、成功利用漏洞可能造成的損害，以及該攻擊是否需要網路存取、本機存取或特定的使用者動作。該專案在過去的公告類別中已使用過這些區分。營運者隨後便可將自身的配置與所描述的條件進行比較。十月二十二日的修訂承諾將針對易於發現類別發布一份附有修復程式的公告，但所揭露的確切事實將取決於第一個被如此分類的已驗證問題。

首次快速揭露將確立節奏

這項書面變更為維護者提供了一條新途徑，但尚未提供任何案例研究。可衡量的順序始於一份已驗證的報告與分類，進展到為全部三個維護分支提供修補程式，最後以簽署的單點版本與一份公告作結。這些步驟的日期將顯示該專案能多快回移植修復程式，以及其公開通知是否僅在每個分支都準備就緒時才發布。一個僅涵蓋三個維護線中兩個的版本，將不符合針對新類別所發布的承諾。

營運者的採用情況較難觀察。可公開觸及的節點可能會公告軟體版本，但網路爬取僅能看到部署的一部分，且版本字串未必會揭露每一個私有服務。交易所與託管機構可能使用從不接受 inbound 公開連線的內部節點。報告升級百分比的 researcher 應說明樣本及其盲點。否則，該數字可能會低估仍暴露的生產基礎設施佔比，或透過計入休眠的公開節點而高估它。

32.0 版的說明指引營運者前往該專案的公告清單以取得安全與更新通知。其生命週期頁面建議使用營運者所能使用的最新主要分支的最新維護版本。下一次禁運揭露預計在 32.0 版發布兩週後進行，並將描述三個已在 30.0 中修復的中等或高嚴重性漏洞。

值得關注的重點

• 首個分類案例：一份公告，指出一個易於發現的缺陷、其受影響的版本，以及快速發布的依據。
• 三個點版本：針對 30.x、31.x 和 32.x 的相應修復，或者若新的大版本到來時更新的維護邊界。
• 公告細節：當礦工、商家、託管商和家庭節點的實際暴露程度不同時，明確區分它們。
• 營運者採用情況：帶有明確樣本的按日期版本測量，以及運行私有節點的服務所披露的資訊。
• 待處理的舊案例：30.0 中三個中或高嚴重性的修復，32.0 的發布說明稱將在通常延遲後進行解釋。

常見問題