BTCPay Server 的热钱包出事了。官方在 X 上发了警报，建议所有实例运营者立刻执行关停服务器，等调查结束再重新上线。
官方的措辞是“收到报告称，多个实例的热钱包正被未授权攻击者清空”。但警报里没有说受影响的具体版本、没有给出确认的损失金额、也没有发布补丁，关停指令不区分版本，一刀切。这种“先全关再调查”的做法，本身就是信号：在弄清楚攻击路径之前，无法判断哪些配置是安全的。
BTCPay 的热钱包之所以是这次事件的核心，和它的设计直接相关。热钱包功能会把种子存储在服务器上，用它在本地直接签署交易，不需要外接硬件设备介入。好处是自动化和便利，代价是一旦服务器被攻破，种子暴露，资金就可以被直接转走。BTCPay 本身是自托管软件，关不关停、什么时候关，最终决定权在每个服务器运营者自己手里，官方只能建议。这也意味着这轮安全事件的波及面，很大程度上取决于运营者响应警报的速度。
有一个时间线值得单独拎出来。10月29日，BTCPay Server 发布了 2.4.7 紧急更新，修复了一个严重漏洞和多个中危漏洞。然后11月1日到2日，热钱包被盗的报告开始出现。官方没有说这次的事件和 10月29日修复的漏洞是否有关，也没有说关停范围是否针对未升级到 2.4.7 的实例。另一个容易混淆的背景是 8 月的一次 LND 凭证泄露事件，当时攻击者可以拿到 macaroon 文件控制闪电节点，但 BTCPay 官方明确说过那次的漏洞不影响链上钱包，包括热钱包。所以拿 8 月的事件来解释这次的热钱包被盗，至少在公开信息层面是不成立的。
眼下最能确认的事情只有一件：热钱包这个功能，在服务器被攻破的场景下，天然不具备隔离能力。种子在服务器上，签名在服务器上，资金安全完全绑定在服务器本身的安全边界上。对于跑着 BTCPay 实例的运营者来说，在官方给出具体的受影响版本范围和修复方案之前，关停实例是当前信息条件下唯一可以主动控制风险的选项。至于攻击者到底利用了什么路径、损失规模有多大、和几天前的版本更新有没有关联，这些问题目前都没有公开答案，等官方调查结论就行。
#BTCPayServer呼吁运营者关闭实例 #BTC $BTC
免责声明：以上内容基于 BTCPay Server 官方警报及公开报道整理，仅作事实梳理与安全机制讨论，不构成任何操作指令或投资建议。运行实例的运营者请以官方最新指引为准。