發生什麼：一則自我指向的通道公告就能讓節點停機
研究者 Nishant Bansal 於 2026 年 10 月 24 日在個人部落格公開一項 Core Lightning（CLN）阻斷服務漏洞，並同步轉貼到 Delving Bitcoin 論壇。根據揭露內容，CLN v25.02 至 v26.04 在收到一則 channel_announcement、而其中 node_id_1 與 node_id_2 是同一個節點時，負責處理 gossip 的 gossipd 程序會觸發斷言並中止；由於 lightningd 把 gossipd 中止視為致命錯誤，整個節點隨之停機。
更麻煩的是，這則公告在崩潰前已寫入磁碟上的 gossip_store。節點重啟後，gossipd 會重新讀入同一筆紀錄並再次中止，因此節點會一直無法上線，直到營運者手動把那筆紀錄刪掉。研究者特別指出，升級軟體本身並不會清除已經存下的那筆紀錄。
揭露文表示，攻擊者只需要和受害節點完成一般的 BOLT 8 握手與 init 交換，成為普通對等節點，再送出一則精心構造的公告即可。揭露中沒有提到任何實際遭利用的案例。
原始證據：為何簽章全對卻會崩潰
閃電網路節點透過 BOLT 7 gossip 學習通道圖。一則 channel_announcement 以 short_channel_id 指認通道，列出兩個端點 node_id_1、node_id_2，並帶四個簽章：兩個節點各一個，以及通道 2-of-2 資金輸出的兩把 bitcoin key 各一個。BOLT 7 原本只要求「發送端」把兩個節點 ID 依字典序排列，讓 node_id_1 較小，這隱含兩者不同，但沒有對「接收端」寫出相應檢查。
研究者引用的 CLN 程式碼顯示，gossmap_manage_channel_announcement() 會解析並驗證簽章，卻沒檢查兩個節點 ID 是否不同。之後 add_channel() 會分別替兩個端點查表、找不到就新建節點，但新節點要到函式最後才加入節點表。若兩端是同一個尚未出現在路由圖中的節點，第二次查表看不到剛建立的第一份，於是又建一次；把第二份加入不允許重複的節點表時，就觸發斷言。
研究者表示，v25.02 之前的版本同樣會接受這種自我指向公告，但因為當時節點表允許重複，只是多存一份而不會崩潰；v25.02 把節點表改成拒絕重複後，才變成可讓節點停機的漏洞。
攻擊步驟依揭露內容是：先建立一個由攻擊者自己掌握兩把鑰匙的 2-of-2 P2WSH 輸出，外觀與一般閃電通道資金輸出無異；再用一個受害者路由圖中尚未出現的新節點 ID 同時填入兩端，並以該節點金鑰和兩把資金金鑰簽名；等輸出累積 6 個確認後送給受害者。資金始終留在攻擊者控制的輸出裡，所以成本只有鏈上手續費。只要該輸出保持未花費，營運者清除紀錄後，攻擊者還能免費再送一次。
修補與時間線：4 月已修，10 月才公開
依揭露文的時間線，研究者於 2026 年 4 月 23 日私下回報，CLN 在 4 月 24 日合併 PR #9082，並於 4 月 25 日釋出 v26.04.1。GitHub 紀錄顯示 PR #9082 的合併時間為 4 月 24 日 02:10（UTC），v26.04.1 發布頁時間為 4 月 25 日 08:25（UTC）。
PR #9082 在解析公告後立即檢查：若 node_id_1 不是嚴格小於 node_id_2，就拒收該公告。這個條件同時排除兩端相同與順序顛倒的情況，因此公告不會被存檔，也不會進入路由圖。v26.04.1 發布說明當時把這項修正描述為依 BOLT 規格拒收順序錯誤的 channel_announcement，可「防止 gossip store 損毀」，並未明說這是可遠端讓節點停機的漏洞。
規格端，BOLT 7 PR #1333 於 5 月 4 日合併，為接收端補上要求：若 node_id_1 不小於 node_id_2，應送出 warning、可以斷線，且必須忽略該訊息。研究者表示這個 PR 是由本次回報促成。
版本對照上，CLN 4 月以後只在 v26.04.1 與 v26.06 系列提供修補，GitHub 發布清單中沒有 v25.x 的後續補丁版；換言之，仍停在 v25.02、v25.05、v25.09.x 或 v25.12.1 的節點都在受影響範圍內。研究者建議升級到目前最新的 v26.06.9（10 月 7 日發布）。
讀者影響：停機不只是離線，也可能牽涉資金
研究者指出，節點停機期間無法監看區塊鏈，若對手方此時廣播已撤銷的承諾交易，或有 HTLC 必須在到期前上鏈領取，節點可能錯過處理時機，使資金面臨風險。這屬於 DoS 衍生的間接風險，不是攻擊者能直接取走資金。
對營運 CLN 的商家、路由節點與錢包服務而言，實際動作有兩件：確認版本已在 v26.04.1 以上；若節點曾在受影響版本下異常且重啟即崩潰，要檢查 gossip_store 是否存有兩端相同的公告並移除。使用 LND、Eclair 或 LDK 的節點，這份揭露沒有評估其是否受影響，本文也不作推論。
AI 觀點分析與推論
AI 觀點：真正的教訓是「先檢查、再存檔」，而不是又一個版本號
我傾向認為，這次漏洞最值得注意的不是攻擊多便宜，而是它把一次性崩潰變成持久停機：不可信輸入先寫入持久儲存，再交給有前提假設的程式碼處理，任何漏網的錯誤輸入都會在每次重啟時重演。對任何接收 P2P 訊息的軟體，這比單一斷言更值得檢討。
第二個訊號是規格層。BOLT 7 只規範發送端，等於假設對方守規矩；惡意對等節點本來就不會守。這次 CLN 回報後才補上接收端要求，10 月 19 日合併的 BOLTs #1357（BOLT11 拒收重複付款雜湊）與 #1352（Simple Taproot Channels 勘誤）也都是類似「把隱含假設寫明」的修補。若此則成立，其他實作可能也有未明文的接收端假設值得盤點；但若後續其他實作的稽核或 fuzz 結果都顯示早已檢查，我會修正為這只是 CLN 特定的程式缺陷。
另一點是揭露節奏：修補在 4 月就發布，但發布說明只寫「防止 gossip store 損毀」，半年後才公開可遠端停機的細節。這給了營運者升級時間，卻也讓不常追更新的節點低估了該版本的重要性。對營運者而言，較穩妥的做法是把閃電節點的小版本更新視為潛在安全更新，而不是等到揭露文出現才行動。
限制與下一步觀察
本文的漏洞機制、v25.02 為起點的說法與停機影響，主要依據研究者單方揭露；CLN 官方發布說明與 PR 可證實修補內容與日期，但本文撰稿時未找到 CLN 另發的詳細安全公告。Delving Bitcoin 上的討論串在撰稿時只有原文一則貼文。
接下來可觀察：CLN 是否補發安全公告或說明 v25.x 的支援狀態；研究者 5 月 6 日開啟、目前仍未合併的 PR #9115（gossipd 訊息處理 fuzz 測試）是否進入主線；以及其他閃電實作是否回應自身對接收端節點 ID 排序的檢查情況。
