币圈界报道：

BTCPay Server 安全事件警示：旧版本系统面临严重资金泄露风险

近期，开源比特币支付平台 BTCPay Server 向所有商户与运营方发出紧急通知，要求立即升级至最新版本。该警告源于一起针对早期安装实例的恶意入侵事件，攻击者利用未修补的安全缺陷获取管理员权限，并成功提取连接热钱包中的私钥，造成资金损失。此次事件再次凸显自托管支付基础设施在补丁管理不及时情况下的脆弱性，距离上一次闪电网络节点被攻破仅过去数月。

受影响实例集中于2.4.1及更早版本，最新版未现异常

根据11月2日发布的更新说明，项目团队确认攻击路径影响的是运行版本为2.4.1（发布于2026年7月23日）或更早的部署环境。调查结果显示，当前最新版本2.4.7并未发现相关资金外泄迹象。此前，项目方已于11月1日建议运营商暂停服务，以便开展深入分析。截至目前，尚未公布具体受影响的服务器数量或被盗资产总额，实际经济损失仍处于评估阶段。

攻击者如何取得管理员控制权？技术细节尚待完全厘清

BTCPay 创始人 Nicolas Dorier 表示，攻击者已在部分实例中实现管理员身份登录。尽管开发团队尚未锁定确切的入侵途径，但现有数据强烈指向低于2.4.2版本存在的潜在漏洞。他强调，采用2.4.7版本的公共服务器未受到波及。这一事实尤为重要，因为 BTCPay 的设计初衷是让商户摆脱中心化支付中介，自主掌控交易流程。

在配置方面，运营商可选择将私钥直接存于服务器上的热钱包，从而支持自动化支付操作；但这也意味着一旦服务器被突破，签名密钥可能被滥用。相较之下，只读模式（Watch-only）将私钥保留在外部，交易需额外签名，显著降低了因服务器沦陷而导致直接盗币的风险，不过仍无法完全规避管理员权限被滥用带来的运营中断威胁。

核心风险点在于过时系统与本地凭证存储，非比特币网络本身缺陷

为何此次攻击与8月事件存在相似性？

本次安全危机紧随8月份另一起重大漏洞之后。当时，攻击者利用一个可被未授权访问的接口，窃取了闪电网络守护进程（LND）的“macaroons”认证文件，进而获得对节点的完全控制权并实施资金转移。该项目随后通过2.4.2版本修复该问题，更新了 LND 组件，并重置了默认管理员凭证。同时临时关闭了公共远程访问功能以降低暴露面。

值得注意的是，8月事件未波及链上热钱包，而本次攻击则聚焦于不同类型的资产。两者共同点在于均发生在2.4.2之前版本的部署环境中，但项目方尚未确认是否由同一漏洞引发，也未排除两起事件之间的关联可能性。此外，10月，Core Lightning 也因类似原因向用户发出升级提醒，虽未报告资金损失，但反映出整个去中心化支付生态正面临持续的安全压力。

运营商应采取哪些行动以防止进一步损失？

最初，项目方建议受影响用户执行标准关机流程，以保障调查完整性。后续公告明确要求所有用户尽快升级至2.4.7版本。该版本修复了通过 Anthropic 安全扫描计划识别出的85项漏洞，包括1个关键级和13个高危级问题。然而，由于尚未明确具体导致本次攻击的漏洞，因此不能简单推断更新即已杜绝风险。

对于仍在使用旧系统的运营商，除了升级外还需警惕潜在信息泄露。若攻击者曾获取管理员权限，服务器内保存的凭证、助记词等敏感数据应视为已暴露。商户须审查账户活动记录，排查异常管理行为，并考虑将剩余热钱包余额迁移至全新、受保护的钱包。项目组已开放渠道，鼓励用户提交事故详情与服务器日志，协助追踪攻击源头。

软件更新仅能缓解未来风险，已泄露凭证需独立处置

自托管支付架构的双刃剑效应正在显现

与依赖中心化服务商的支付系统不同，BTCPay Server 采用分布式部署模式，每个实例独立运行。这意味着项目方无法统一强制更新或冻结服务，其安全性高度依赖于用户的维护意识与技术能力。虽然这种架构赋予商户更高的自主权，但也带来了补丁延迟、配置错误等风险。尤其对持有流动资金的商业实体而言，热钱包虽提升效率，却也放大了单点故障的财务后果。

当前，主流加密平台正面临新一轮关于热钱包安全性的审视。尽管底层机制各异，但共性在于运维责任的下放。接下来的关键在于项目方能否披露攻击手法、受害规模及实际损失金额。在这些信息明确前，运营商应基于自身软件版本、管理日志与交易行为主动评估风险，并建立更严格的安全响应机制。