Electrum／官方：惡意伺服器可置換剛廣播交易並誘使 RBF 加費簽名——4.8.3 修補；野外已有用戶失資

重點摘要

Bitcoin 輕客戶端錢包 Electrum 於二零二六年十月二十四日公開安全公告 GHSA-6jp4-8v48-cc5v：惡意伺服器可吞掉剛廣播的交易，並以把輸出改為攻擊者地址的假未確認交易覆寫錢包歷史；若用戶隨後以 Replace-by-Fee（RBF）加費，客戶端會簽出有效付款予攻擊者。維護團隊確認野外已有伺服器進行攻擊，兩宗用戶報告中至少一宗加費後失資；受影響為 4.8.3 之前版本，同日釋出的 4.8.3 會驗證自身地址輸入簽名。本文已核對官方 GitHub Advisory、4.8.3 發行說明與 CoinDesk 轉述，來源真實性已驗證。

Electrum／官方：惡意伺服器可置換剛廣播交易並誘使 RBF 加費簽名——4.8.3 修補；野外已有用戶失資

Bitcoin 輕客戶端錢包 Electrum 於二零二六年十月二十四日公開安全公告 GHSA-6jp4-8v48-cc5v：惡意伺服器可吞掉剛廣播的交易，並以把輸出改為攻擊者地址的假未確認交易覆寫錢包歷史；若用戶隨後以 Replace-by-Fee（RBF）加費，客戶端會簽出有效付款予攻擊者。維護團隊確認野外已有伺服器進行攻擊，兩宗用戶報告中至少一宗加費後失資；受影響為 4.8.3 之前版本，同日釋出的 4.8.3 會驗證自身地址輸入簽名。本文已核對官方 GitHub Advisory、4.8.3 發行說明與 CoinDesk 轉述，來源真實性已驗證。

Electrum／官方：惡意伺服器可置換剛廣播交易並誘使 RBF 加費簽名——4.8.3 修補；野外已有用戶失資

引言

輕客戶端為了省下完整節點的成本，必須把「未確認交易記憶池視圖」託付給連線中的 Electrum 伺服器——這是設計取捨，也寫在官方 FAQ。二零二六年十月，有人把這層信任變成可實操的盜幣路徑：伺服器先扣住用戶剛送出的合法交易，再塞一筆簽名無效、輸出卻指向攻擊者的衝突交易進錢包歷史；用戶若以為「卡住了」而按 RBF 加費，客戶端就會為這筆假交易簽出真正有效、且手續費更高的付款。Electrum 於十月二十四日公開披露並釋出 4.8.3；CoinDesk 於十月二十六日交叉轉述。對香港與亞洲大量使用軟件錢包、硬體錢包搭配輕客戶端、或自建／託管 Electrum 伺服器的個人與機構而言，這是一則「加費前必須核對完整收款地址與金額」的硬警示。來源真實性已驗證。

一、核心事件

  1. 披露與修補時間（官方 Advisory 時間線）：
    • 十月十一日：user1 私下通報，當時尚未意識到 bump_fee 攻擊向量；
    • 十月十八日：user2（Raju-K12）私下報告，指對置換後的交易加費後失資；
    • 十月二十三日：4.8.3 於 git 標註，含修復提交；
    • 十月二十四日：4.8.3 二進位釋出，並公開 GHSA-6jp4-8v48-cc5v。
  2. 受影響範圍：Electrum 4.8.3 之前；修補版本 4.8.3。官方標示嚴重程度為 High。
  3. 攻擊機制（官方摘要）：
    • 客戶端廣播新交易 tx1 時，惡意主伺服器可吞掉該廣播，使其未進入比特幣 P2P 傳播；
    • 伺服器以衝突的 tx2 更新客戶端歷史：輸出改為攻擊者地址；tx2 簽名無效，但輕客戶端設計下當時未驗證；
    • 錢包介面只顯示未確認的 tx2，tx1 不再出現；
    • 若用戶對 tx2 手動執行 RBF 加費，客戶端會以更高手續費為該交易簽出有效簽名，資金流向攻擊者。
  4. 野外證據（官方 Remarks）：
    • 「部分伺服器正在進行此攻擊」；
    • 兩宗用戶報告：user1 發現廣播後歷史變成另一筆交易（該案未報失資）；user2 加費後失資；
    • user1 稱 tx1 未在 P2P 傳播，顯示伺服器扣住廣播；
    • 兩案均指攻擊者輸出地址被打磨至與合法地址末四字元相同，提高快速掃過時的誤認機率；
    • 依 user2 報告，tx2 曾以零手續費構造，誘導用戶以為卡住而加費。
  5. 修復內容：提交 90fe308；客戶端在把記憶池交易加入本地歷史前，會驗證 wallet.is_mine 輸入的簽名。只連可信／自建伺服器的客戶端不受此攻擊路徑影響。
  6. 修復後仍存的邊界（官方）：即使修補後，仍只驗證「屬於本錢包」的輸入；「入帳」類未確認交易不在此驗證範圍。輕客戶端缺乏完整共識／腳本解釋器；若要覆蓋非 is_mine 輸入，須遞迴驗證未確認父交易直至已上鏈交易——已上鏈交易本來就有 SPV 驗證。
  7. 官方建議：升級至 4.8.3（並養成定期更新習慣）；在未升級前，每次簽名（含加費）都核對輸出地址與金額。下載應以 electrum.org 為準並核對簽章。
  8. 媒體核實：CoinDesk（十月二十六日）轉述上述機制、至少一宗失資、以及「勿在可疑環境用 pip／Python 驗證」類比以外的錢包操作提醒；金額與惡意伺服器身分官方未公開，本文亦不臆造。

以上時間、版本、機制與「野外已有攻擊／至少一宗失資」均摘自 Electrum GitHub Security Advisory 與 4.8.3 發行說明；CoinDesk 僅作交叉轉述。本文不捏造失資金額、受害地址清單或未具名伺服器 IP。

二、技術原理

  1. 輕客戶端的信任邊界：Electrum 不跑完整節點，主連線伺服器被託付未確認交易視圖——官方文件早已說明此設計。漏洞不在「RBF 協議本身違法」，而在客戶端對伺服器回報的未確認交易缺少簽名驗證，使「顯示中的待確認交易」可與鏈上可簽名意圖脫節。
  2. 「吞廣播 → 假歷史 → 誘加費」三拍：攻擊者需控制用戶當下使用的伺服器（或誘使用戶連上惡意伺服器）。扣住 tx1 避免網路其他人看到合法付款；塞入簽名無效的 tx2 只為騙過 UI；真正盜幣發生在用戶主動對假交易做 RBF 簽名的那一刻——此時客戶端用用戶種子／硬體錢包簽出有效、高費的付款。
  3. 末四字元撞車與零費誘導：地址磨成與合法收款地址相同結尾，專門打擊「只看最後幾個字元」的人工核對習慣；零費則提高「我去 bump 一下」的機率。兩者都是社會工程與 UI 信任疊加，而非共識層破綻。
  4. 硬體錢包也不能自動免疫：CoinDesk 轉述 user1 案例涉及二取三多重簽名、並曾在兩部 Trezor 上核對合法付款；之後仍在軟件歷史中看到被置換的未確認交易。硬體裝置保護的是私鑰不外洩，不自動保證主介面顯示的「待加費交易」仍是當初那筆。
  5. 修補的務實取捨：只驗證 is_mine 輸入，是在輕客戶端資源限制下先堵住「把用戶自己的幣簽給攻擊者」這條主路徑；入帳詐騙與更複雜的未確認父交易鏈仍須靠伺服器信任、自建節點或完整驗證升級路徑長期治理。

四、日常應用

開發者

若產品內嵌 Electrum、Electrum 協定伺服器或自研輕客戶端：立即盤點依賴版本，強制客戶端 ≥ 4.8.3；對「未確認、且花費本錢包 UTXO」的交易在寫入本地歷史前做簽名驗證；加費／RBF UI 必須重現完整收款地址與金額並要求明確確認。營運公共 Electrum 伺服器者應假設用戶會質疑伺服器誠信，公開運維身分、日誌與升級政策。

企業

財資、Web3 業務與託管運維若以 Electrum 作熱錢包或簽批前端：把伺服器連線改為自建或合約約定的可信節點；禁止員工臨時改連來路不明的公共伺服器；把「加費前核對完整地址」寫進操作 runbook；對多重簽名／硬體錢包流程加一層獨立出帳核對（另一裝置或只讀瀏覽器）。審計供應商時詢問輕客戶端版本與伺服器託管位置。

一般用戶

儘快升級至 Electrum 4.8.3，並只從官方網站取得安裝包、核對簽章。加費或重送前，逐字核對收款地址（不要只看末四碼）與金額；若廣播後歷史「變成另一筆」、或出現零費卡住卻導向陌生地址，先停止簽名，改以可信伺服器或區塊瀏覽器對照。長期可考慮自建 Electrum 伺服器或改用完整節點錢包，以降低對陌生伺服器的依賴。

香港與亞洲

香港持牌平台、家族辦公室與個人大額持幣者常用軟件錢包搭配硬體裝置作出帳。此次事件提醒：私鑰在硬體裡，不代表螢幕上的「待加費交易」仍是你剛核對過的那一筆。團隊若提供錢包託管、鏈上財資或 Web3 基礎設施，應把輕客戶端升級、可信伺服器與出帳雙人核對納入標準交付，而不是假設「用了硬體錢包就完事」。

若企業需要在香港規劃錢包架構、節點／伺服器託管、智能合約與鏈上出帳流程的安全工程，可參考 YSK Limited 香港 Web3 區塊鏈開發服務：https://ysk.hk/services/web3-blockchain （產品與版本事實見 https://ysk.hk/llms.txt；YSK Kit v1.6.5、YSK Server v1.1.30）。

五、專業評價

值得關注之處

  • 官方以 GitHub Security Advisory 公開完整時間線、攻擊步驟與修補提交，並承認野外利用與失資個案，透明度高。
  • 修復直接對準「is_mine 未確認輸入缺簽名驗證」根因，且明確區分自建／可信伺服器不受影響，方便機構立即降風險。
  • 點出末四字元磨地址與零費誘導，對操作教育極具實用價值。
  • 4.8.3 發行說明同步列為 security update，與 Advisory 日期可互相核對。

需要留意的地方

  • 官方未公布失資金額與惡意伺服器清單，機構難以做精確 IOC 封鎖，只能以升級與可信連線為主。
  • 修補後對「入帳」未確認交易仍不驗證，社會工程空間未完全關閉。
  • 依賴公共隨機伺服器的用戶，在升級前每一筆加費都處於高風險窗口。
  • 媒體轉述易與其他「錢包被盜」敘事混淆——決策應以 GHSA 原文與自身連線設定為準。

結語

Electrum 這次事件把輕客戶端的老問題說得很清楚：你信任的若是「幫你看記憶池的伺服器」，對手就能在加費那一步，把螢幕上的假交易變成鏈上真轉帳。十月二十四日公開的 GHSA-6jp4-8v48-cc5v 與 4.8.3 已堵上主攻擊路徑，但野外利用與至少一宗失資代表這不是理論題。香港與亞洲的個人與機構眼下最務實的三步是：升級到 4.8.3、改連自建或可信伺服器、加費前逐字核對完整地址與金額——硬體錢包是必要條件，不是充分條件。

如需協助在香港設計錢包／節點架構或 Web3 出帳安全流程，歡迎聯絡 YSK Limited：https://ysk.hk/services/web3-blockchain · WhatsApp +852 6160 4242 · [email protected]。

參考來源

  1. Electrum／spesmilo：GitHub Security Advisory GHSA-6jp4-8v48-cc5v（2026-10-24 公開）— https://github.com/spesmilo/electrum/security/advisories/GHSA-6jp4-8v48-cc5v
  2. Electrum：RELEASE-NOTES — Release 4.8.3（October 23, 2026）（security update）— https://raw.githubusercontent.com/spesmilo/electrum/4.8.3/RELEASE-NOTES
  3. CoinDesk：Bitcoin wallet bug let rogue servers steal funds when users tried to speed up payments（2026-10-26）— https://www.coindesk.com/tech/2026/10/26/bitcoin-wallet-bug-let-rogue-servers-steal-funds-when-users-tried-to-speed-up-payments
  4. Electrum 官方網站（下載與簽章核對）— https://electrum.org/

延伸閱讀 · 相關服務與產品

相關文章