Bitcoin Core 週二一次公布三個安全漏洞的細節，全部在 2025 年 10 月就已修補，卻壓了 13 個月才對外說明。其中一項讓數千個對外可達的主網節點，把所有經 Tor 進來的陌生連線都當成受信任的電腦；另一項高風險漏洞則會讓礦工節點產不出有效區塊範本，直到有人重啟。第三項能讓惡意對等節點把區塊處理卡住 10 分鐘，而且可以無限次重來。
（前情提要：Bitcoin Core 首爆記憶體漏洞！礦工可遠端執行他人節點程式碼，全網 43% 節點未修補）
（背景補充：AI 正逼企業償還拖了 40 年的技術債）
比特幣 Core 在 11 月 10 日一次公布三個安全公告，三項漏洞全部已在 2025 年 10 月的版本裡修掉，細節卻壓了 13 個月才對外說明。其中最容易被低估的一項，是讓數千個對外可達的主網節點，把每一個經 Tor 進來的陌生連線都當成自己人。
外來連線怎麼變成「受信任」
先看節點的角色。節點是一臺檢查、轉發比特幣交易，並儲存完整區塊鏈的電腦，它會限制外部連線能送進多少流量，用來擋住把節點淹掉的嘗試。Bitcoin Core 的 whitelist 設定，則是對操作者信任的連線放寬這些限制，例如同一個區域網路裡的其他機器。
問題出在廠商把 Bitcoin Core 與 Tor 綁在一起出貨。Tor 的用途是隱藏網路位址，而經 Tor 進來的連線，看在節點眼裡，來源 IP 是那支 Tor 常駐程式的位址，通常和節點同一臺機器、同一個區網。只要這個位址落在 whitelist 指定的網段裡，外部訪客就跟著繼承了受信任的許可權。依該則公告的說法，結果是「數千個對外可達的主網節點，把所有傳入的 Tor 連線都放進白名單」。沒設定 whitelist 的節點從頭到尾不受影響。
這條被編號 CVE-2025-62860，評為中風險，由 Martin Zumsande 與 Antoine Poinsot 在 2025 年 9 月 12 日通報。Zumsande 三天後就送出修補，在套用白名單許可權時排除 Tor 的傳入連線。修補進了 28.3、29.2 與 30.0；30.0 之後，走洋蔥位址進來的連線永遠不會被放進白名單。Poinsot 另在 9 月 19 日私下通知受影響的軟體供應商該怎麼處理，公告沒有點名是哪些廠商。
礦工節點會「產不出塊」
第二項是高風險的 CVE-2025-62861，牽涉節點如何處理互相競爭的鏈。當網路放棄某一條鏈，被丟棄區塊裡的交易會被重新加回待處理池 mempool，而且刻意跳過防垃圾與拓樸政策，用意是忠實還原那些曾被確認的交易。但 28.0 版引入的手足驅逐規則沒有被這個豁免擋住：TRUC 交易依 BIP 431 的規定，只能有一個未確認父、一個未確認子；當一筆新交易讓某個 TRUC 父多出第二個未確認子，Core 會把原本那個子當成可替換物件驅逐。reorg 還原時這道邏輯照樣啟動，於是還原出一種在區塊裡合法、在 mempool 裡卻拼不回來的交易組合。
後果很具體：節點會試著組出包含「輸入已不存在」交易的區塊，然後被自己的有效性檢查打回。受影響的礦工節點在重啟之前，做不出任何有效的區塊範本。Bitcoin Core 把它列為高風險，影響範圍是 28.0 到 28.2、29.0 到 29.1，改用 30.0 之後的版本就沒問題。Niklas Goegge 在 2025 年 9 月 26 日通報，公告裡並沒有記錄任何實際攻擊。
第三個漏洞：把區塊處理卡住 10 分鐘
第三項是中風險的 CVE-2025-62859，走的是壓縮區塊 compact block 的重建流程。公告描述，節點在重建壓縮區塊之後會先清掉下載狀態，才去檢查 witness malleation；一旦這個檢查失敗，節點會回頭向同一個對等節點用 GETDATA 要完整區塊，而這個請求帶著 10 分鐘的 timeout。惡意對等節點只要搶先宣告一個壓縮區塊，就能讓受害節點卡在這 10 分鐘裡。
更麻煩的是可重複性。若攻擊者掌握受害節點的三條高頻寬連線，或受害者跑的是隻處理區塊的 -blocksonly 設定，這個卡頓可以無限次重來。這項由 Eugene Siegel 在 2025 年 4 月 28 日通報，是三個漏洞裡最早被發現的，修補進了 30.0（10 月 10 日）與 29.2（10 月 14 日）。
為什麼壓了 13 個月才講
Bitcoin Core 的慣例是，中風險與高風險漏洞的細節，要等到最後一個受影響的版本退出支援之後兩週才公開。這一輪的最後一個受影響版本是 29.x，它在 2026 年 10 月 27 日結束支援，兩週後的 11 月 10 日正好就是這次的公告日。這個時間差不是遺漏，而是留給操作者升級的緩衝。
不過這套時程正在鬆動。Core 在 2026 年 10 月改過規則，對容易被重新發現的漏洞，包括丟一句提示給 AI 模型就能找回來的型別，改成修補與公告同步發布。這次的三個 CVE 走的仍是舊的長時程，理由是它們沒被歸進那個新類別。
市場影響
把三件事放在一起看，訊號很清楚：比特幣真正脆弱的地方不是共識規則，而是節點軟體的實作與部署細節。這三個漏洞沒有一個能偷幣、能雙花，但它們分別能讓節點瞎掉、讓礦工產不出塊、讓 Tor 使用者的隱私防護直接失效。相較於 2026 年 5 月那顆可被遠端執行程式碼的記憶體漏洞，這次的風險等級低了一階，曝露面卻更廣，因為踩到 Tor 白名單缺陷的前提不是有人惡意設定，而是廠商照著說明打包。
這裡最值得記下的是根因型別。它不是程式碼算錯，而是預設值與部署拓樸對不上：whitelist 本來要信任的是自家機器，結果 Tor 常駐程式剛好站在那個位址上，於是整條外來連線被一起信任。這種瑕疵不會出現在模糊測試或程式碼審計裡，只會出現在真實世界的安裝方式裡，而公告沒點名任何一家打包廠商，等於把查核責任丟回社群。
接下來有三個觀察點。第一，28.x 與 29.0、29.1 還有多少節點在跑，這決定高風險那項漏洞的真實曝險。第二，各家把 Core 與 Tor 綁在一起出貨的安裝包，預設值有沒有跟著改，這件事沒人公告就得自己查。第三，當 AI 讓重新發現舊漏洞變得便宜，開源專案「先修好、壓 13 個月再說」的慣例還能撐多久；Core 已經為此改了一次規則，其他專案大概很快要面對同一個選擇。
📍相關報導📍
白帽駭客揭露 Cosmos 暗藏 0-day 漏洞！節點重啟恐全面死鎖癱瘓，官方卻將通報當垃圾郵件
Apple漏洞獎金被「AI假報告」塞爆！真正白帽獵人送不進去
如何讓 AI 程式寫得更慢，但更正確：多模型 PR 審查，讓 Bug 機率壓到最低
