BTCPay Server 告知运营商在比特币热钱包遭攻击后关闭

区块链文库报道：

BTCPay Server 紧急警告：因热钱包遭窃，要求所有运营商立即下线服务

允许商家接受比特币支付而无需向第三方处理器分成的开源软件 BTCPay Server，于 2026 年 11 月 1 日晚通知所有实例运营商关闭其服务。此举源于该项目开始收到报告，指出热钱包正遭到未经授权的攻击者盗取。

我们收到报告称，BTCPay Server 上的热钱包正被未经授权的攻击者扫荡。如果您正在运行实例，请将其关闭（执行 ./btcpay-down.sh），直到我们完成调查。
—— BTCPay Server (@BtcpayServer) 2026年11月1日

该警报发布于 2026 年 11 月 1 日下午 5 点 25 分（美东时间），这是该项目自今年 8 月涉及闪电网络凭证泄露事件以来，首次要求其整个自托管用户群将服务器离线。此次报告的矛头指向了不同的目标：位于 BTCPay Server 内部的链上热钱包，而非包裹在其周围的闪电网络通道。

11 月 2 日，比特币交易价格接近 78,375 美元，较前 24 小时上涨约 0.8%。随着更广泛的市场在 10 月 29 日币安被盗事件后继续重建，BTCPay 的警告是一个独立的、较为局限的故事，主要关注比特币支付堆栈中自托管的边缘部分，而非引发市场波动的重大事件。然而，它恰逢一个高度强调安全的周次。

被迫拔线的自托管支付堆栈

BTCPay Server 并非托管方。商家下载该软件并在自己的硬件或云实例上运行，这意味着交易所面临的风险被另一种风险所取代：运营商自己的服务器现在持有私钥。该项目的钱包文档描述其热钱包功能使用存储在服务器上的种子来签署交易，因此资金可以在没有外部签名设备的情况下移动。

这种架构正是下达关机指令的原因。能够在服务器上签名的热钱包，也是攻击者一旦访问到服务器即可利用的签名工具。项目建议运行 ./btcpay-down.sh 并让实例保持离线状态，直到调查结束，这承认了一个事实：目前，该项目尚无法确定哪些版本或配置是安全的。

该警告并未局限于特定版本。这正是此次事件与常规补丁公告的区别所在：BTCPay 并没有告诉运营商“升级到 X 版本”或“禁用 Y 功能”，而是让他们完全停止软件运行。这是该项目自发布安全公告以来发出的最强指导。

无损失数据、无版本限制、无补丁

11 月 1 日的公告中显著缺失的是任何确认的损失数字。该项目表示正在接收热钱包“被扫荡”的报告，但并未说明有多少实例受到影响、损失了多少比特币、涉及哪些版本或配置，以及何时可能推出补丁。

这一空白至关重要，因为 BTCPay 是自托管的：该项目无法查看商家的服务器以像中心化交易所审计自身数据库那样统计损害。任何损失总数都必须通过链上活动加上运营商报告来重建，而该项目尚未发布此类数据。

创始人 Nicolas Dorier 向媒体表示，早期发现指向受影响的服务器运行的是早于 2.4.2 的版本，攻击者以管理员身份登录，但他 cautioning 调查人员尚未确定如何获得该访问权限。他的言论属于初步性质，仅归因于他个人，而非项目发布的正式技术调查结果。

紧急发布三天后的警告

该警告紧随 BTCPay Server 2.4.7 之后，这是一个日期为 2026 年 10 月 29 日的紧急发布版本。发行说明将该更新描述为修复了通过 Anthropic 的 OSS 扫描程序报告的 85 个安全问题：包括 1 个严重问题、13 个高危问题、52 个中危问题和 19 个低危问题。

“此漏洞修复版本解决了安全性、可靠性和支付会计问题，”说明中写道，并感谢 “Anthropic 及其 OSS 扫描程序报告这些发现并提供可重现的步骤和拟议的修复方案”。

时间安排令人不安，但这本身并不能证明两者之间存在联系。2.4.7 版本的发布与热钱包被盗报告之间相隔两天多，且该项目已明确表示，该版本中修复的漏洞与当前的盗刷事件之间没有确凿的联系。Dorier 观察到，该项目公共服务器上运行的 2.4.7 版本未受攻击，这一观察结果虽有用，但不能证明每个更新后的安装都是安全的，而项目并未试图模糊这一区别。

8 月的先例是不同的创伤

BTCPay Server 曾经历过类似情况，但并非完全相同。2026 年 8 月，该项目确认存在一个缺陷，允许攻击者从受影响的实例中获取 LND 管理员 macaroon 凭证，并利用它们盗取连接的闪电网络节点的资金。该事件促成了 2.4.2 版本的发布以及类似的更新或关闭服务器的要求，这也是当前关机指令读起来如此熟悉的原因。

然而，8 月的缺陷明确不影响 BTCPay 内部的标准链上钱包，包括其热钱包。这就是新报告引人注目的原因：它们指向的正是 8 月漏洞范围之外的钱包类型。闪电网络通道的盗取和链上热钱包的扫荡是不同的攻击面，项目对新报告采取全面关机的态度表明，它认为这是一个真正独立的向量，而不是早期事件的重演。

更广泛的自托管比特币堆栈在 2026 年下半年一直在应对同一类问题。8 月底，Core Lightning 告诉其节点操作员升级或离线，原因是集群中的 AI 报告错误，这是一次来自不同实现的结构性相似呼吁。

关闭、保持离线、等待根本原因

对于运行实例的商家或爱好者来说，具体的步骤很短。运行项目的关机命令，让服务器保持离线，并等待官方声明，指明受影响的版本、根本原因和补救路径。不应将单独更新视为清除活跃妥协的手段，因为入口点尚未确定。

随着调查的深入，运营商还应区分项目的确认指令和社区报告。警报中没有任何内容确立了总数、根本原因或安全重启点，且项目一直谨慎地不声称拥有其中之一。

这次事件提醒人们，即使去除了交易所，自托管基础设施仍将风险集中在服务器上。今年早些时候，Bitget 确认发生了一起价值 3.516 亿美元的热钱包泄露事件，这是一起交易所侧的事件，说明了无论谁持有密钥，热钱包密钥管理仍然是行业内价值最高的目标。

自托管边缘在 2026 年下半年经历了艰难的时期。8 月，Coldcard 硬件钱包漏洞导致用户损失约 1.14 亿美元，Galaxy 研究人员将另一波损失与弱种子生成联系起来，导致比特币冷钱包损失约 7000 万美元。BTCPay 事件符合同样的模式：攻击面不再仅仅是交易所，而是运营商自行运行的持钥软件。

所有关键数字仍然缺失

下一个具体的信号将是 BTCPay Server 的后续消息：一份技术事后分析报告、一个封闭该向量的版本，或者一旦项目能够统计流动金额后的损失总数。在此之前，现行的指令是让受影响的实例保持离线，而未解的问题包括入口点、受影响的版本范围以及被盗取的总额。

这是一则正在发展的故事，而非已解决的事件。其核心事实已经确立——在项目面对热钱包扫荡时要求运营商关闭服务——但每一个关键的数字，从损失额到易受攻击的版本，仍隐藏在项目自身的“接收报告”措辞之后。