BTCPay Server 官方於十一月二日公布調查結果，確認十一月一日起接獲多宗熱錢包比特幣與萊特幣被盜報告，攻擊鎖定仍運行 2.4.1（二零二六年七月二十三日發布）或更早版本的實例；攻擊者以有別於八月 2.4.2 修補路徑的手法利用該舊漏洞。官方稱十一月一日警告發出時已運行 2.4.2 或更新版本者暫未見受影響，並強烈建議仍處 2.4.1 或更早、或警告後才升級者，把剩餘資金掃至新錢包後改上全新虛擬機，勿只就地更新。硬體錢包等支出金鑰不在伺服器上的資金未受此次盜竊影響。來源真實性已驗證。
BTCPay／官方：熱錢包遭盜——攻擊鎖定 2.4.1 或更早版本；籲轉移新機與新錢包；硬體錢包未受影響
開源、可自架的加密貨幣收款處理器 BTCPay Server 於二零二六年十一月二日在官方網誌發布事故說明，指十一月一日收到多宗熱錢包（hot wallet，即把可花費金鑰存放於伺服器上的錢包）比特幣與萊特幣被盜報告。調查顯示攻擊針對仍運行 2.4.1（七月二十三日發布）或更早版本的實例，並以不同於八月七日 2.4.2 所修補路徑的手法利用該漏洞。官方強調：十一月一日警告發出時已在 2.4.2 或之後版本者，暫未見因此次攻擊受影響；若仍在 2.4.1 或更早（即使警告後才升級），應把剩餘熱錢包資金掃至新錢包、以全新種子上線全新虛擬機，並輪替可能外洩的密碼與金鑰。支出金鑰不在伺服器上的錢包（包括硬體錢包）資金未受此次盜竊影響。來源真實性已驗證。本文重點包括：版本界線與時間線、為何「只升級」不足、以及對香港自架收款與節點營運的實務含義。
一、核心事件：舊版熱錢包遭鎖定，官方要求重建而非就地升級
版本界線清楚：2.4.1 及更早中招；2.4.2 起暫未見受影響
BTCPay Server 是讓商戶自架收款、把比特幣等數碼資產直接收進自有錢包的開源方案，可走鏈上與 Lightning Network，減少中介手續費。官方說明，熱錢包把花費所需金鑰放在伺服器本機；一旦攻擊者取得管理權或利用舊漏洞進站，即可發起未授權付款。
調查把受影響範圍收窄為 2.4.1 或更早。該漏洞本身已在 2.4.2（八月七日） 修復；其後八月至十月仍陸續有 2.4.4、2.4.5 等保安加固版本。官方坦言希望當日對仍停留舊版的用戶發出更強提醒。十一月一日警告發出時已運行 2.4.2 或更新版本的實例，官方表示暫未見因此次攻擊受影響。
為何不能只按「更新按鈕」
官方與復原指引強調：若攻擊者早已取得存取權，單純升級無法清走後門或殘留憑證；錢包結餘未變亦不代表未被入侵。建議步驟包括：
一、在可信裝置上建立新錢包與新種子，把舊熱錢包剩餘資金掃入；重用舊種子等於把風險帶到新機。
二、把舊伺服器下線，並先保留調查所需日誌與交易紀錄。
三、開設全新虛擬機，從可信來源安裝最新支援版本並接上新錢包；不要把整部舊伺服器還原到新機。
四、在可信裝置上撤銷並更換舊機可能接觸過的密碼與存取金鑰，包括託管、SSH、應用、API 與 Lightning 相關憑證；不要在舊機上輸入新憑證。
若已發生盜竊或見到未授權存取跡象，即使事後已升級，仍應視整機與密鑰為已妥協，並走同一套重建流程。
二、技術細節：時間線、託管商下線與已知收款地址
官方公布的 UTC 時間線
- 八月七日：發布 2.4.2，修補相關漏洞。
- 八月至十月：繼續推出包括 2.4.4、2.4.5 等保安更新。
- 十一月一日 13:46：事故報告中出現一筆錢包清空（wallet drain）；官方尚未確定攻擊者最早何時開始利用該漏洞。
- 十一月一日 20:56：收到首封報失電郵。
- 十一月一日：聯絡 LunaNode 等 VPS 託管商，要求預防性把 BTCPay 實例下線以保護客戶。
- 十一月一日 22:25：在 X 向社群發出警告，呼籲營運者先關閉伺服器以便調查。
- 十一月二日：發布調查更新，指明受影響版本為 2.4.1 及更早，並交代託管商已採取預防性下線。
已知目標地址與損失總額的謹慎表述
官方列出事故報告中出現的比特幣與萊特幣收款地址，但明確指出部分地址活動似早於已知盜竊、完整時間線與哪些交易屬本事故尚未確立，因此不應把地址結餘或交易歷史當成已確認損失總額。BleepingComputer 等業界報道亦轉述官方敦促更新、以及調查聚焦攻擊者如何以管理員身分登入舊於 2.4.2 的實例；撰寫本文時以官方網誌為準，不臆測未公布的損失數字或完整利用鏈細節。
報失方面，官方請受影響者電郵 [email protected]，提供當時版本、上次更新日期、發現時間（含時區）與相關公開交易識別碼／地址，並向本地執法機關報案；切勿傳送種子、私鑰、密碼或其他憑證。
三、日常應用場景
1. 開發者與技術團隊
若你維護自架 BTCPay、Lightning 或同類收款／節點堆疊，應把「版本滯後」當成一級事故風險：訂閱官方發布渠道、把保安更新納入變更窗口，並以基礎設施即代碼方式做到可重建（rebuild）而非只就地 patch。金鑰衛生方面，熱錢包只留日常營運所需；支出金鑰盡量放硬體錢包或離線方案。日誌與配置外傳前必須剔除密鑰。考慮到官方亦提到自動化與 AI 驅動攻擊令舊版曝露窗口縮短，監控異常出金、陌生管理員登入與非預期版本回退同樣重要。
2. 企業與隱私敏感行業
零售、餐飲、跨境電商或接受加密貨幣付款的中小企若自架收款節點，等於把「可花金錢鑰」放進與網店／VPS 相同的信任邊界。應在採購與營運手冊寫明：允許的最高落後版本、事故時強制重建流程、以及託管商聯絡窗口（今次 LunaNode 等已配合預防性下線）。財務與合規團隊宜假設熱錢包屬高風險營運浮存，定期把盈餘轉至冷儲或託管金鑰分離方案，並保留鏈上證據鏈以便報案與追蹤。
3. 一般用戶
個人若只是向商戶付款，風險主要在商戶端；若你自己架設 BTCPay 收款，請立即在介面底部確認版本。已在 2.4.2 或之後且於十一月一日警告前已升級者，按官方說法暫未見受此次攻擊影響，但仍應保持最新支援版本。仍在 2.4.1 或更早、或警告後才升級者，勿心存僥倖——掃走餘額、換新種子、新虛擬機、輪替憑證。硬體錢包收款在此次盜竊中未被點名受影響，但仍建議重建曾曝露的舊伺服器。
4. 香港與亞洲市場視角
香港虛擬資產交易平台須持牌、商戶與 Web3 團隊亦常見自架節點、收款網關或 Lightning 基礎設施。金管局與證監會近期持續強調代理式金融、代幣化結算與網絡保安管治；自架熱錢包被盜提醒的是另一條平行線：開源並不自動等於已打補丁。本地團隊對外判開發、VPS 與私有雲專案，應在合約要求保安更新 SLA、事故重建演練，以及「金鑰不與應用同機」的預設架構——這與持牌平台的熱／冷錢包分隔、以及企業雲端金鑰輪替紀律一致。
四、專業評價與潛在考量
優勢
- 官方同日（十一月二日）事故稿版本界線清楚（2.4.1 及更早 vs 2.4.2 起暫未見受影響），並附 UTC 時間線與託管商協作細節，方便營運者對號入座。
- 復原建議強調「全新虛擬機＋新種子＋憑證輪替」，符合真實入侵後的取證與根治實務，而非只推一個版本號。
- 明確區分熱錢包與支出金鑰離機（含硬體錢包）的影響範圍，避免恐慌性誤導。
需要留意的地方
- 官方尚未確立攻擊最早開始時間，亦不以公開地址結餘作為損失總額；外界報道的金額不宜直接當成官方數字。
- 技術利用細節為免擴大攻擊面可能未完整公開；防禦端應以版本與重建流程為準，而非等待完整 exploit 說明。
- 八月已有 2.4.2 修補，十一月仍見舊版中招，凸顯「發布修補 ≠ 用戶已升級」的長期營運缺口；AI 加速掃碼與利用只會令此缺口更貴。
結語
當開源收款堆疊把熱錢包金鑰留在可遠端觸達的伺服器上，版本滯後就不再只是技術債，而是可直接變現的攻擊面。BTCPay Server 以清楚的版本界線與「重建優於就地升級」回應十一月熱錢包盜竊潮，也再次提醒：硬體錢包與冷儲能縮小爆震半徑，但舊機若曾曝露，仍須當整機已妥協處理。若你的團隊正在香港為商戶、DApp 或節點場景做自架收款、錢包架構與鏈上基建加固，可參考 YSK Limited 的 Web3 區塊鏈開發服務：https://ysk.hk/services/web3-blockchain
參考來源
- BTCPay Server 官方〈Security Incident Affecting BTCPay Server 2.4.1 and Earlier〉：https://blog.btcpayserver.org/btcpay-server-security-incident-2-4-1-and-earlier/
- BleepingComputer 報道（業界轉述與操作建議交叉核對）：https://www.bleepingcomputer.com/news/security/btcpay-server-warns-of-hot-wallet-thefts-targeting-outdated-instances/
- BTCPay Server 官方〈Security Advisory: Update BTCPay Server to 2.4.2 Immediately〉（八月漏洞修補背景）：https://blog.btcpayserver.org/security-advisory-btcpay-server-2-4-2/