Securing BTCPay Server: Why only updating to version 2.4.4 cannot protect your Lightning nodes

Disclaimer: Content does not constitute investment advice. Trading involves risks—please invest with caution!

直奔主题：BTCPay Server 2.4.4 更新关闭了 Lightning 节点的公共默认路由

因为这是将你带到这里的核心问题，我们开门见山：BTCPay Server 2.4.4 的更新关闭了你 Lightning 节点的公共默认路由。它并没有移除你自己构建的路由。因此，任何曾通过自己的反向代理暴露服务器 LND 接口的人，现在都有两项任务：进行更新，并撤销该访问权限。BTCPay Server 项目在其 2026 年 9 月 8 日的公告中明确指出了这一点。

触发此次更新的并非新的盗窃事件。该项目发现，有自动化程序正在探测那些被手动重新开启此访问权限的服务器。目前尚未报告通过此路线成功接管的情况，且项目方未将此事件与八月的事件联系起来。好消息是：这里存在一个窗口期，可以在不造成损失的情况下解决问题。

对于持有者或商家而言，这不仅仅是服务器细节的问题。自托管支付服务器是接收比特币付款、Lightning 节点密钥和运营余额交汇的关键点。失去那里的访问权限意味着失去真金白银，而不仅仅是配置信息。这就引出了第二个同样重要的问题：有多少余额必须永久停留在连接到互联网的节点上，哪些部分应存入冷钱包？如果你尚未划定这条界限，我们的硬件钱包比较指南比任何进一步的代理规则都是更好的起点。

当前状况：机器人正在调用未受保护的 LND 端点

项目方公开描述了这一模式。自动化程序反复调用 LND 编程接口的特定路径：即更改钱包密码的端点 /lnd-rest/btc/v1/changepassword。受影响的服务器明确是指那些在 BTCPay Server 于八月默认禁用此访问后，被手动重新开启访问的服务器。

关键之处在于：只要 LND 钱包仍处于锁定状态，该端点就不需要身份验证。这在狭义上不是漏洞，而是接口的设计使然。锁定的钱包无法对任何人进行身份验证，因此解锁和更改密码的路径必须在没有凭据的情况下可达。只要该路径仅在服务器内部可达，它是无害的。只有将其发布到开放的互联网上，才会成为入侵途径。

Macaroon、LND 和反向代理：其余内容依赖的三个术语

LND 是闪电网络（Lightning Network）的常见实现之一，闪电网络是支付层，能在几秒内以极低的手续费结算比特币转账。如果你的 BTCPay Server 接受 Lightning 付款，底层几乎总是 LND。

Macaroon 是 LND 用于授权命令的凭证。可以将其视为具有分级权限的密钥文件。管理员 macaroon（admin macaroon）是主密钥：谁持有它，谁就控制节点的钱包及其支付通道。

反向代理是处理来自互联网的传入请求并将其传递给正确内部服务的服务器进程。BTCPay Server 自带一个。许多运营商在它旁边或前面设置了第二个反向代理，例如让移动钱包在他们外出时与其节点通信。正是这种自建转发规则与此事有关。

为什么 LND 重启后确实存在时间窗口

这个过程并不引人注目，但这正是其有效的原因。每次 LND 重启后，钱包最初都是锁定的。BTCPay Server 有一个内部解锁机制，可自动提供密码。在服务启动到解锁生效之间有一段短暂的时间间隔。

如果在此期间接口可从开放互联网访问，攻击者可能更快得手。项目方冷静地描述了后果：谁在那一刻提交已知密码，谁就可以设置新密码并获得由 LND 签发的控制节点的管理员 macaroon。从此，主密钥属于他人。

过去的一个细节加剧了这一问题：旧版 BTCPay 安装使用共享默认密码创建 LND 钱包。因此无需猜测。任何知道默认密码的人只需在正确的时刻敲门即可。

攻击路线并非永久状态，而是一个间隙：LND 重启与 BTCPay Server 自动解锁之间的短暂窗口。

八月盗窃案与九月探测是两个独立事件

区分两者很重要，因为德语媒体的报道在八月停止，两个事件容易混为一谈。

较早的事件：2026 年 8 月 7 日

项目方发布了针对 2.4.2 版本的安全建议。所有早期版本都存在一个漏洞，未经身份验证的远程攻击者可借此检索 LND 的 macaroon 文件。项目方明确确认该漏洞已被利用，用户受到影响，资金被盗。BTCPay Server 自身的链上钱包（包括热钱包）不受此影响；相比之下，LND 链上钱包中的余额属于受影响的节点。项目方和支持者后来提出奖励，金额为任何追回比特币的 10%，上限为 3 BTC（当时约合 19 万美元）。

新事件：2026 年 9 月 8 日

目前尚无reported damage。这涉及寻找入侵途径的机器人以及项目方采取的预防措施。将两者混为一谈会声称没有任何来源支持的损失。

BTCPay Server 2.4.4 更新实际关闭了什么

根据项目方的说法，它在两个方面解决了上述序列问题。

第一：终结共享密码。

新的 LND 镜像不再使用共享默认密码创建钱包。每个新生成的钱包都会获得自己的随机密码。仍在使用旧默认密码的现有钱包会在启动时自动迁移。这消除了依赖先验知识的攻击部分。

第二：在网络边缘进行阻断。

Docker 设置在捆绑的反向代理本身中阻止了创建和解锁钱包的未认证路由。通过公共默认路径，重启窗口现已关闭。

2.4.4 带来了进一步的变化，虽然与攻击无关，但可能会影响你的操作。结账时的 NFC 付款现在默认关闭，必须在商店设置中重新开启。无金额发票默认被阻止。通过连接到计算机的读卡器设置 Boltcards 的功能已移除；改为由 BTCPay Server 打开相应应用程序。由于破坏性更改，使用 WHMCS 集成需要插件版本 4.0.0 以及新生成的 API 密钥。受邀商店用户必须先接受邀请。此外，销售点模块不再允许每个请求单独的通知地址；模块中存储的地址适用。

标准 Docker 设置同时也进行了较大升级：Bitcoin Core 从 29.2 升级到 31.1，LND 升级到 0.21.3-beta。由于 Knots 遵循了一条偏离主链的分支，项目方移除了对 Bitcoin Knots 的支持。故意运行 Knots 的用户应在更新前而非更新后阅读相关内容。此外，与主机的绑定更加紧密：应用容器不再拥有广泛的 SSH 访问权限，而仅获得一小列表维护命令的密钥。

为什么你自己的反向代理规则不受更新影响

This is the core, and it is the same sentence that the project party already wrote in August: updates to BTCPay Server will not shut down the access routes you manage separately. The forwarding rules in your own reverse proxy, the forwarding port on your router, the Tor service you set up yourself-updates don't know about these and can't undo them.

The instructions from the project party are therefore unambiguous: Do not manually expose the LND interface to the Internet through your own reverse proxy. If you have already done so, revoke that access and update your server. Do both, read in order, not as an alternative.

If you have been exposed through your own route in August, you should also rotate node credentials. The update to 2.4.2 automatically regenerates standard installed macaroons; this does not apply to self-managed paths. You are familiar with the same logic, as shown by an analysis of the Core Lightning vulnerability at the end of August: The dangerous assumption has never been the vulnerability itself, but the idea that a version upgrade will handle everything that follows.

External Lightning access restored, but limited to explicit opt-in

For many carriers, the August shutdown is painful because it also removes legal routes: mobile wallets such as Zeus that operate your own nodes while you are away. The project has never denied this and announced an orderly return in September.

Current status: 9 月 11 日合并了一项路由更改，提供了远程访问的受支持选项，同时 LND 和 Core Lightning 的接口默认保持关闭。这与旧情况的关键区别在于：访问存在，但你必须故意开启它，并且它将通过项目方维护的路径运行，而不是通过你自己的手工操作。

在实践中这意味着：如果需要远程访问，请使用提供的开关，停止建立自己的转发规则。并利用这个机会检查手机上的哪个钱包应该有权访问你的节点。软件钱包比较列出了哪些软件钱包支持哪些连接类型；并非所有钱包都具备相同的权限级别，受限 macaroon 的远程访问远比拥有主密钥要安全得多。

窗口持续多长时间取决于你的硬件和通道数据库的大小。你无法据此规划。

运营商检查清单：今天要做的事

确认你的版本。运行版本显示在管理区域页脚中。如果低于 2.4.4，这是你的首要任务。
更新。Docker 安装通过“服务器设置 › 维护 › 更新”进行。其他管理方式的安装通过常规途径进行。
查找你自己的转发规则。检查你的代理配置，查看是否有任何规则将 /lnd-rest/out 以下的任何内容指向互联网。也要考虑路由器上的转发端口和你自己设置的 Tor 服务。
移除找到的任何路由。不要注释掉它们并留在那里；删除它们并重新加载服务。
轮换凭证如果你的节点可通过自行管理的路径访问。生成新的 macaroons，使旧的失效，并在移动钱包中重新设置存储的连接。
如果需要，重新设置远程访问通过提供的设置而非你自己的规则进行。

如果你没有时间正确处理第三点和第四点，八月通知中的建议精神仍然适用：无法到达的节点也无法被探测。周末有几个小时无法远程访问，好过拥有一个开放的端点。

如何判断你的 LND 节点是否被入侵

项目方发布了针对八月事件的检查例程，此处同样适用。在你的节点中查找你未发起的付款。注意你未触发的通道关闭和你未知的交易对手。将你的链上余额和通道余额与自己的记录核对。任何无法解释的情况都是继续调查的理由，而不是放松警惕的理由。

为了保持冷静，请注意：截至目前，尚未有人报告通过九月观察到的路线发生接管。检查是尽职调查，而非损害评估。

需要单独考虑的是项目方在同一公告中披露的第三个事件：其自托管的插件构建服务器于 9 月 2 日被发现遭到入侵。据项目方称，仅影响插件开发者，不影响其用户。已发布的插件经过检查，未被恶意版本替换，所有访问令牌均已轮换。存储的电子邮件地址可能已被读取；任何注册用户都应预期未来几周会出现钓鱼尝试，并相应地对待意外消息。

该事件对接受比特币支付的德国商家的意义

在德国，BTCPay Server 主要被小型商家、贸易企业、俱乐部和希望不经中介接受比特币的在线商店使用。吸引力在于付款直接进入你自己的钱包。期间没有服务提供商持有资金。

这种设计有其反面，本案展示了这一点：当没有人介入时，也没有人承担责任、阻止或退款。对于托管提供商，攻击是他们的麻烦。在你的服务器上，那是你的责任。更新、访问路由以及运营余额与储备之间的划分的责任完全由你承担。

由此得出一个独立于任何单一漏洞的简单操作规则：节点上只保留日常支付流量所需的余额。超出部分定期转移到不连接互联网的存储中。自动化流出并每周而非每季度运行一次，可将任何未来事件造成的损失限制在可管理的范围内。

记录和税务：税务局对比特币支付的要求

一点在安全话题中往往被忽略，但最晚在下次审计时会遇到你：如果你的业务接受比特币作为付款，流入即为业务收入。重要的是流入时的欧元价值，且需要记录。德国所得税法第 23 条规定的一年持有期（可使私人销售免税）不适用于商业资产。随后出售的收益和亏损留在业务中，并通过该法第 15 条运行。

对于增值税，立场早已确定：欧洲法院在 C-264/14 案中裁定，将传统货币兑换为比特币再换回免征增值税；德国联邦财政部在 2018 年 2 月 27 日的通函中在德国实施了这一规定。无论在此方面如何，你实际的货物或服务供应仍需纳税，以欧元衡量。

在实践中这意味着：对于每笔付款，你需要时间、比特币金额、应用的欧元汇率以及该汇率的来源。BTCPay Server 在其发票数据中保留这些详细信息，并允许你导出。在服务器迁移或事件使数据库不可用之前使用这些数据。记录需遵守保存要求，且在保存期间必须保持可访问，这源于德国税法典第 147 条，适用于 SQL 数据库，就像适用于活页夹一样。