币圈界报道：

BTCPay Server 暴露重大安全漏洞，旧版本用户面临资金外泄风险

近期，开源比特币支付平台 BTCPay Server 发出严重警告，要求所有运营商立即更新其部署实例。此前有攻击者利用未修复的漏洞，成功侵入部分早期版本的安装环境，并非法提取了关联热钱包中的资产。该事件再次凸显自托管支付系统在缺乏及时补丁管理下的脆弱性，距离上一次闪电网络节点被攻破仅过去不足三个月。

受影响版本为2.4.1及以下，最新版未现资金损失

根据11月2日发布的更新说明，调查确认攻击向量针对的是运行版本2.4.1（发布于2026年7月23日）或更早的实例。项目组明确表示，目前无证据显示2.4.7版本存在类似资金被盗情况。此前，11月1日已发出临时停机指令，要求相关服务器在排查未经授权取款行为期间下线。截至目前，官方尚未公布具体受波及的部署数量或被盗金额，实际财务影响仍待进一步披露。

管理员权限被滥用，攻击路径仍存疑

创始人 Nicolas Dorier 表示，攻击者已在目标实例中以管理员身份完成登录。尽管尚无法完全还原获取权限的具体方式，但现有线索指向低于2.4.2版本的软件存在可被利用的缺陷。值得注意的是，采用2.4.7版本的公共服务器未受侵害。作为去中心化支付解决方案，BTCPay 允许商户自主配置钱包模式，包括将私钥直接存储于本地服务器的热钱包架构。

此类设置虽支持自动化交易流程，却也带来显著风险：一旦服务器遭受入侵，攻击者可能绕过用户授权直接发起转账。相比之下，仅读取（Watch-only）模式将私钥保留在外部，交易需独立签名，从而降低了因服务器失守而导致资金直接流失的可能性。然而，即便如此，非法管理员访问仍可能破坏系统配置和运营连续性。

核心威胁源自基础设施老化，非底层协议缺陷

两次攻击暴露相似防御短板

本次事件紧随8月发生的另一场安全危机。当时，攻击者通过一个漏洞窃取了闪电网络守护进程（LND）的认证令牌，进而获得对节点的控制权并实施资金转移。该问题在8月7日发布的2.4.2版本中得到修复，同时项目方关闭了默认的远程管理接口以降低暴露面。关键区别在于，那次事件并未波及链上热钱包。

此次攻击则聚焦于热钱包资金，且均发生在2.4.2之前版本的实例上。尽管两者存在时间与版本重叠，但开发团队尚未确认是否由同一漏洞引发，或是否存在协同攻击模式。此外，10月，Core Lightning 亦因检测到未修补节点遭攻击而发出升级提醒，但未报告资金损失。

强化防护须多管齐下，不能仅依赖版本更新

初始阶段，项目方建议受影响用户按标准流程关闭服务器以配合调查。随后，正式呼吁将系统升级至2.4.7版本。此版本包含通过 Anthropic 安全扫描发现的85项修复，涵盖1个高危与13个严重级别漏洞。然而，由于尚未锁定具体致损漏洞，不能简单推断此次更新即已防范当前攻击。

若服务器已被攻陷，存储在其中的密钥、助记词等敏感信息应视为已泄露。商户需核查异常管理操作记录，审查交易流水，并尽快将剩余热钱包余额迁移至全新、隔离的安全环境中。项目方已开放渠道，邀请受影响用户提交事故详情与日志文件，协助溯源分析。

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

自托管架构的双刃剑效应凸显

相较于集中式支付服务商，BTCPay Server 采用分布式部署机制，各商户独立运维自身实例。这意味着平台无法强制执行全局更新或暂停服务。这种设计赋予用户高度自主权，但也意味着安全责任完全落在运营方身上——从补丁管理、配置策略到服务器防护均需自行负责。

对于依赖热钱包维持自动支付与退款功能的企业而言，这一权衡尤为突出。持续可用的资金虽保障业务流畅，但同时也放大了单点故障带来的潜在损失。当前事件反映出，市场正重新审视自托管支付系统的整体韧性。未来关键进展将取决于攻击手法的精确还原、影响范围的界定以及经济损失的量化。在这些信息明朗前，运营商应基于版本状态、访问日志与交易行为综合评估自身风险敞口。