币圈界报道：

BTCPay Server 暴露严重安全漏洞，旧版实例面临资金被盗风险

开源比特币支付平台 BTCPay Server 近期发布警示，要求所有商户与支付运营商立即升级其部署系统。此前有攻击者利用未修复的漏洞，成功侵入部分早期版本的安装实例，并窃取了关联热钱包中的资产。该事件凸显了过时自托管基础设施在面对网络威胁时的脆弱性，距离上一起导致闪电网络节点失守的安全事故仅过去不足三个月。

攻击路径尚未完全查明，但低版本系统为关键突破口

根据11月2日发布的更新说明，调查确认攻击向量针对的是运行版本2.4.1（发布于2026年7月23日）或更早的实例。项目方明确表示，最新版2.4.7未发现资金被窃迹象。此前，11月1日已发出临时停机指令，要求运营商在开发团队完成初步调查前关闭服务器。目前，受影响实例数量及具体损失金额仍处于保密状态，实际财务影响尚待评估。

管理员权限泄露是核心风险点，攻击者实现越权登录

BTCPay 创始人 Nicolas Dorier 表示，攻击者已在受波及实例中以管理员身份完成登录。尽管具体渗透手段尚未完全厘清，现有证据指向版本低于2.4.2的软件存在可被利用的缺陷。他强调，运行2.4.7版本的公共服务器未受侵害。这一特性至关重要，因为 BTCPay Server 的设计允许商户在无中心化中介的情况下自主处理比特币交易。

当前配置中，运营商可选择连接外部钱包，或启用将私钥直接存储于服务器的热钱包模式。前者虽提升安全性，但后者因支持自动化流程而被广泛采用，也带来了更高的联网风险。一旦服务器被攻破且攻击者获得足够权限，即可绕过用户授权执行转账操作。相比之下，只读模式（Watch-only）将私钥保留在外部，交易须独立签名，从而显著降低因服务器被入侵而导致资金流失的可能性，但仍无法完全排除管理账户被滥用带来的运营中断风险。

核心威胁来自过时系统与服务器凭证暴露，非比特币协议本身漏洞

本次事件与8月漏洞有何相似之处？

此次事件紧随8月发生的一起安全危机之后。当时，攻击者通过一个漏洞获取了闪电网络守护进程（LND）的管理员凭证，借助“macaroons”文件实现未授权访问，进而可能操控节点并转移资金。该项目随后在8月7日推出2.4.2版本，修复了相关问题，并重置了默认凭证，同时暂时禁用了公共远程访问功能以减少暴露面。

值得注意的是，8月事件并未波及链上热钱包。而此次攻击则发生在热钱包层面，攻击者在窃取资金前已取得管理员控制权。虽然两起事件均影响2.4.2之前的版本，但项目方尚未确认是否源自同一漏洞，亦未揭示两者是否存在技术或行为上的关联。

此外，其他比特币基础设施也遭遇类似挑战。10月，Core Lightning 在收到针对未修补节点的攻击报告后，向运营商发出升级警告，但未证实有资金实际被盗。

运维人员应如何应对：从即时关机到全面风险排查

最初，BTCPay 建议用户通过标准流程关闭受损服务器，以便开展深入调查。后续公告则强烈推荐所有用户尽快升级至2.4.7版本。该版本修复了由 Anthropic 安全扫描计划识别出的85项问题，包括1个关键级和13个高危级漏洞。然而，项目方仍未公开指出具体是哪一项补丁阻止了本次攻击，因此不应将其视为对已发生事件的直接防御证明。

对于仍在使用旧版本的机构而言，除升级外还需评估潜在泄露风险。若攻击者已获取管理员权限，则服务器上保存的所有凭证与助记词均应视为已外泄。商户应核查异常管理活动记录、审查交易流水，并将剩余热钱包余额迁移至全新、经加固的钱包中，前提是怀疑原系统已被攻陷。项目方已启动事故上报机制，鼓励受影响用户提交详细日志与事件描述以协助追踪。

软件更新只是第一步，已泄露凭证需单独处置以防范二次损失

自托管架构下的安全责任边界再度浮现

区别于依赖中心化服务的支付平台，BTCPay Server 采用分布式部署模式，各商户独立维护自身实例。这意味着项目方无法统一强制执行更新或暂停服务，其安全性高度依赖于个体用户的补丁管理能力、钱包配置策略与系统运维水平。对于持有流动资金的商家而言，热钱包虽能保障自动结算效率，但也意味着一旦服务器被攻破，潜在经济损失可能极为严重。

当前，主流加密支付生态正经历新一轮关于热钱包安全性的审视。尽管底层机制各异，但共通逻辑在于：自托管等于责任。未来的关键信息将聚焦于攻击手法还原、受影响商户规模及确切财务损失。在这些细节披露前，运营商必须基于软件版本、管理员日志与交易行为进行主动风险评估，以构建有效的防御体系。