BTCPay Server在11月2日公布的正式通告，把这次热钱包失窃事件的处置要求推进了一步：运行2.4.1及更早版本的商户，即使还没有发现余额减少，也被建议迁往全新服务器、使用新钱包。单纯把版本号升级，不能消除攻击者此前可能取得的访问权限。对收取比特币或莱特币的经营者而言，需要核对的是警告发出时的部署状态，以及服务器究竟能替谁签名。
同样显示最新版，两家商户可能面临不同处置
官方通告区分了两种时间路径。如果在11月1日警告发出前，实例已经运行2.4.2或更新版本，团队表示没有观察到这次攻击对这些服务器造成影响。如果原先运行2.4.1或更早版本，在警告之后才更新，迁移服务器和更换钱包的建议仍然适用。升级后的当前版本，不能单独证明升级之前没有发生入侵。
这一差别决定了排查不能只截取后台底部的一张版本信息。商户还要找更新记录、部署日志和此前使用的版本。假设一家店长期更新，另一家店直到收到警告才从旧版本升级，两者今天都能显示相同的版本号，但后一家仍有一段可能暴露的历史。这个例子说明分类方法，并不代表已经确认任何具体商户被攻击。
据官方11月2日通告，攻击针对2.4.1及更早版本，使用了不同方式利用2.4.2已经修复的漏洞；2.4.2发布于8月7日。不能因为版本界线相同，就把此前事件的资金类型、凭据取得方式和损失范围全盘套入本次事件。现有公开材料能支持的是受影响版本与恢复要求，不能据此补写一条未经披露的完整攻击链。
相关下载： Binance全球顶级交易所 v3.22.4大小：306.2M
补丁修入口，资金和权限还要分别收回
官方通告的恢复要求包括：在可信设备上建立使用新助记词的钱包，把旧热钱包剩余资金迁入；将旧服务器下线，在替换前保留相关日志和交易记录；部署全新虚拟机，从可信来源安装受支持的最新版，再连接新钱包。官方明确提醒，不能把旧服务器完整恢复到新机器。
这些动作解决的是不同问题。补丁阻止已知漏洞继续被利用，却不能让已经泄露的秘密自动失效。新虚拟机减少把旧环境中的恶意改动一并带过去的机会；新钱包及新助记词改变资金支配所需的密钥。把旧助记词重新导入一台新服务器，仍然保留同一套资金控制权。如果攻击者已经掌握旧种子，换机器并不能使那份种子失效。
通告还要求从可信设备撤销并替换旧服务器能够访问的凭据，包括适用的托管、SSH、应用、接口与闪电网络凭据，不要把新凭据输入旧机器。这里的判断范围比钱包余额更广：服务器可能既负责收款，也能调用其他服务。只转走链上资金而继续沿用可疑访问密钥，仍可能保留后续操作通道。
下面的原文摘录排版取自官方通告，非网页截图。它强调的是已有访问权限的残留风险，不能被解读为每一台旧版本服务器都已确认遭到入侵。
余额未变也不足以排除先前攻击。攻击者是否已经访问、何时会使用掌握的秘密，与某个查看时点有没有转出记录，并不是同一个问题。因此，官方建议覆盖了没有观察到失窃的旧实例；若已出现失窃或未授权访问迹象，则应把整台机器及其秘密视为失陷，即使事后已经完成升级。
暂停收款带来的损失，需要用可恢复性衡量
对小商户来说，迁移有明确成本：结账页面可能停用，订单需要对账，新的收款环境需要验收。但继续使用一个无法排除权限残留的环境，会让新收入进入同一套风险结构。比较两者时，应看后续新增资金是否仍暴露，而非仅比较停机时长。官方通告给出了重建方向，并没有保证所有部署都能在固定分钟内恢复，本文也没有对任何商户环境进行操作测试。
把签名留在服务器外，改变的是损失路径
BTCPay官方钱包文档说明，热钱包可以使用保存在服务器上的种子自动签署交易；它也支持硬件钱包和部分签名比特币交易，即PSBT。后者允许先构造交易，再在兼容设备或钱包中检查并签名，随后导回广播。两种部署都能让商户收款，但支出时需要动用的权限所在位置不同。
本次官方事件通告表示，支出密钥保存在服务器之外的钱包，包括硬件钱包，未受这次失窃影响，并继续建议采用这种收款安排。这项结论有明确边界：它说明本次观察到的偷款路径没有夺取这些钱包的支出权限，不代表旧收款服务器可以继续保持原状。通告特意保留了对旧服务器进行重建的建议，即使商户将钱包密钥保存在别处。
下面的概念插图将收款处理与签名权限分开展示。它不是实际产品界面，也没有用图中物件数量表示受害者或失窃金额。
将签名移出服务器，能够降低服务器被控制后直接支出储备资金的能力，但会改变日常退款、提现与自动化付款的操作方式。需要持续自动付款的商户，可以沿官方建议，只在热钱包保留日常所需余额，把其余资金转入支出密钥位于服务器外的钱包。这里没有适合所有商户的统一金额；退款频率、订单波动和资金调拨速度不同，所需运营余额也不同。
相关下载： 欧易okx交易所 v6.195.1大小：549.4M
地址余额不能直接变成事件损失统计
通告列出了报告中识别出的比特币与莱特币目的地址，同时提醒，部分活动似乎早于目前收到的失窃报告，完整时间线以及哪些交易与事件有关尚未确定。因此，即使区块浏览器可以查出余额和交易记录，也不能把地址累计收款直接写成已确认损失。地址可能包含早期活动，余额还会受后续转出影响；两种口径都需要交易归因。
官方列出的时间线以UTC为准：11月1日13:46发生了一笔报告中描述的钱包转出，20:56收到首封失窃邮件，22:25向社区发出关停警告。团队明确表示，尚未确定攻击者最初开始利用漏洞的时间。已知第一笔报告事件，不等于攻击活动的最早时间；商户不能用这个时点排除更早的异常访问，也不能把时区不同的本地日志直接叠在一起比较。
这也解释了为什么日志和交易记录需要在替换前保留。交易记录能帮助确定资金转移，部署与访问日志则帮助还原版本和权限变化。两类证据回答不同问题，缺少其中一类，就更难判断一次升级发生在风险暴露之前还是之后。公开报道的早期版本曾写到技术细节尚未披露，后续官方通告已经补充了恢复步骤，处置判断应以这份更新后的说明为主要依据。
目前足以支持的判断是：旧实例的恢复需要同时处理机器、密钥与访问凭据，当前余额和当前版本都只是检查的一部分。尚缺的则是完整攻击时间线、受影响数量及经核实的总损失。后续若有正式复盘，应再核对攻击条件和排除范围是否变化；在此之前，把未披露的损失写成确定数字，或把“未观察到影响”写成永久安全承诺，都会让商户作出错误的恢复决策。
用户评论