BTCPay 曝險盤點（2026）：更新後還要重建嗎？版本分流與復原準備

BTCPay 已經更新，餘額也沒少，舊機就能繼續收款嗎？這篇 BTCPay 曝險盤點先查你在警報當下跑哪一版。BTCPay Server 11 月 2 日事故指引明確要求：警報時仍是 2.4.1 或更早版本，即使之後更新、尚未發現失竊，也應依新伺服器與新錢包程序處理。

你要完成的是一份逐機、逐錢包的盤點與交接紀錄：目前版本、警報時版本、更新時間與證據、各錢包的金鑰位置、可疑交易，以及復原準備的待辦負責人。準備可信任的另一台裝置、既有部署或託管紀錄；若主機已離線，先向託管商取紀錄，不要只為補欄位而重新開機。本文依官方文件整理核對與復原準備，沒有登入讀者主機或實測資金搬移。

BTCPay 曝險盤點：先補警報時版本，別只抄今天的版本

官方時間線把警報列在 2026 年 11 月 1 日 22:25 UTC。比較更新先後時，請把託管工單、部署紀錄的時區也寫上，統一換成 UTC 再比對；只寫「11 月 2 日更新」不足以分清先後。這個時間是公開警報時間，官方仍未確定攻擊者最早何時開始利用漏洞。

對仍可正常管理、且未出現可疑活動的實例，官方的現版查法是登入後看頁面底部，抄下完整版本；已隔離或疑似遭入侵的主機，請由託管商或維運人員協助取證。接著從原有更新工單、部署成功紀錄、監控或服務商保存的資料，找出「哪一版何時開始實際運行」。

把「預約更新」「下載套件」和「新版部署完成」分開記。只有目前版本畫面，無法證明警報前就已更新；只有某次部署完成，也要確認其後是否回退版本。找不到舊紀錄就填「未知」，請託管商補資料。這是本文採用的保守核對方法，不是官方另外訂出的版本門檻。

每台實例複製一份；空白改填「未知」，不要填猜測值
實例代號／託管商：
目前版本／查核時間（含時區）：
警報時版本：
警報基準：2026-11-01 22:25 UTC
最近更新：舊版本 → 新版本
更新完成時間（含時區）：
證據位置／是否有其後回退：
實例可疑活動（含時間與時區）：
錢包子欄（每個商店、每個幣別各複製一組；勿填秘密）
  商店代號／幣別／錢包代號：
  金鑰位置狀態：機上／機外／未知
  判斷依據（既有紀錄位置）：
  此錢包的可疑活動／公開交易 ID：
分流：A／B／C／待查
新 VM／新錢包／憑證替換：待辦與負責人

先判斷異常活動，再按版本分流；資料不足保留待查

• C：已失竊，或有未授權存取跡象。優先歸入 C，不論是否也符合版本條件；把整台機器與其秘密資料視為遭入侵，走同一復原程序。即使事後已更新，也不能只把案件標成「已修補」；並依下方回報段準備事故資料。
• B：警報時為 2.4.1 或更早版本。走全新伺服器與新錢包的復原程序。後來才更新、餘額看起來正常，都不解除這項建議；即使花費用私鑰放在機外，舊伺服器的重建建議仍然適用。
• A：警報時已在 2.4.2 或更新版本。官方表示，尚未看到這次攻擊影響這些伺服器的情況。這個說法限於本次已觀察到的攻擊，不能擴張成整台機器從未被入侵的保證。

官方也明說，更新本身不能移除攻擊者可能已取得的存取權；錢包餘額未變，也不能排除較早發生的攻擊。版本修補與事故復原因此要分開驗收。

如果警報時版本未知，先標「待查」，不要放入 A。本文建議暫停恢復收款的決定，請服務商協助補齊歷史版本與時間；若仍無法排除舊版曝險，就請原廠或具備事故處理能力的人員協助按重建方向規劃。這是資料不足時的保守處理，不代表已證實你遭到入侵。

金鑰在哪裡，決定要搬的是哪些資金

熱錢包把能花費資金的私鑰存放在伺服器上。官方 Wallet 文件說明，啟用熱錢包時，可以使用機上保存的 seed（錢包恢復種子）自動簽署。機外簽名則把簽署留在另一個錢包或硬體裝置。

每台機器都要按商店與幣別重複填寫上面的錢包子欄，讓可疑交易對應到該錢包；不要因為其中一個錢包用機外簽名，就把其他錢包也填成機外。只查既有設定紀錄與建立方式，不要為了填表匯出、截圖或傳送 seed／私鑰，也不要把它輸入可疑主機。曾經輸入過而範圍不清楚，就把這一欄保留待查。

事故指引表示，花費用金鑰放在伺服器外的錢包，包括硬體錢包，未受這次失竊影響；官方仍建議用這種方式收款。這句話回答的是已知失竊的資金範圍，舊版伺服器的重建建議仍適用。別用「硬體錢包還在手上」替整台主機解除處置。

復原準備與交接：新錢包、舊機留證、乾淨 VM 的順序

進入 B 或 C 後，照官方順序準備；這裡的「新伺服器」是乾淨的虛擬機器（VM），不必先把它理解成購買實體電腦。資金搬移需要簽署並廣播交易；若不知道如何從可信裝置處理舊熱錢包，先找服務商或原廠協助，不在可疑頁面嘗試輸入備份。

1. 在可信裝置建立新錢包，使用新 seed。依官方指引把剩餘熱錢包資金轉入新錢包；不要在新主機重用舊 seed。執行前核對幣別與目的地址，並在可信簽署端檢查交易內容。本文不提供一條跨錢包通用的搬幣指令。
2. 讓舊伺服器離線並保存證據。替換前保留相關日誌與交易紀錄；已離線者維持隔離。不要先刪除舊機，才發現託管商也沒有留紀錄。
3. 配置全新 VM。從可信來源安裝最新受支援的 BTCPay Server，接上新錢包；不要把整台舊伺服器還原到新機。版本選擇可從 專案官方 Releases核對，2.4.2 是這次分流的歷史門檻，不是本文要求你停留的安裝目標。
4. 從可信裝置撤銷並替換可能曝露的憑證。新憑證不輸入舊主機；下節逐項記錄。

預期留下的成果，是新 VM 與新錢包各自有識別紀錄、舊機保持離線、相關交易與日誌已保全。如果託管商只完成原機更新，請明確追問是否另建乾淨 VM、是否沿用整機映像，以及新錢包是否重用舊 seed。

把舊機能接觸的憑證逐項撤銷，別只改登入密碼

官方要求替換可能曝露的密碼與存取金鑰，範圍包括適用的託管、SSH、應用程式、API 與 Lightning 憑證。依你的部署逐項判斷「舊機可否接觸」，不要把沒有用到的服務硬列成受害。每項記錄服務名稱、撤銷完成時間、新憑證部署位置與驗收人；清冊只寫識別標籤，不放憑證內容。

把「產生新的 key」和「舊 key 已撤銷」分兩格。完成後在可信環境驗收必要連線；如果服務未恢復，先檢查新環境是否配置正確，別把新 key 再貼回舊機來測。

回報事實、處理進度與必要附件，排除秘密資料

歸入 C，也就是已失竊或發現未授權活動時，官方指定聯絡 security@btcpayserver.org。本文只協助準備資料，由你自行寄出。內容包括當時版本、最近更新時間與已知的前一版本、發現異常的時間及時區、相關公開交易 ID 與地址；失竊者也應向所在地執法機關報案。

如果已有安全取得的交易紀錄，可按 官方 Transactions 說明找到交易 ID，點開區塊瀏覽器後抄完整編號。下圖是官方文件範例，不是本次被盜交易；畫面上的省略編號不能直接當成完整回報資料。已離線的可疑主機不必為了看這個畫面重新上線，先交給服務商取證。

分享前移除日誌與設定中的 seed、私鑰、密碼及其他憑證；原始證據另外保存在受控位置，不公開上傳整份備份。官方列出的收款地址尚不能證明所有交易都屬本案，因此不要把該地址總餘額寫成你的損失，或寫成已確認的全案損失。

回報草稿（勿填任何秘密）
實例代號：
異常時版本／更新前版本：
最近更新完成時間與時區：
發現異常時間與時區：
公開交易 ID／幣別／地址：
異常描述：已確認事實與未知項分開
已完成處理：新錢包／資金處理／舊機離線／新 VM／撤權
附件：已去秘密的相關日誌摘錄
仍待確認：歷史版本、時間或金鑰位置的缺口

完成後逐台回讀：分流是否有歷史證據？B／C 是否只做了原機更新？新錢包是否使用新 seed？舊憑證是否確實撤銷？把未完成項交給具名負責人與期限；「未知」留在紀錄上，直到取得能改變分流的證據。