BTCPay Server 严重漏洞正遭受主动攻击：立即升级并轮换凭据

在这款开源比特币支付处理器警告存在一个据称已在野外被利用的严重安全漏洞后，BTCPay Server 管理员正被敦促立即采取行动。项目已要求服务器运维人员升级到 2.4.2 版本，确认服务器页脚已显示更新后的版本，并轮换可能已暴露的凭据。

对于使用 BTCPay Server 接受比特币和闪电网络支付的商户、节点运营者以及加密原生企业来说，这并不是一则例行维护通知。该警告涉及可能的未授权访问，在最坏情况下甚至可能导致直接的资金损失。

发生了什么？

BTCPay Server 是一套广泛使用的自托管比特币支付处理系统，它已向管理员发出警报，称存在一个影响服务器安全的严重漏洞。该问题由 Bitcoin Red Team 的一名成员报告，这个团队是一个专注于安全的组织，负责审查与比特币相关的基础设施。

截至撰写本文时，BTCPay Server 团队尚未公开披露该漏洞的完整技术细节。在漏洞正在被积极利用期间，这是一种常见且负责任的做法，因为过早公开利用机制可能会帮助攻击者锁定未打补丁的系统。

目前已知的信息包括：

• BTCPay Server 已发布 2.4.2 版本，作为必须安装的安全更新。
• 管理员应通过检查服务器页脚是否显示更新后的版本来确认升级是否成功。
• 如果无法立即升级，应暂时关闭服务器。
• 运维人员应轮换已暴露的认证材料，尤其是与 Lightning 相关的 macaroon。
• 在 BTCPay Server 内创建的热链上钱包用户应立即转移资金，并重新创建这些钱包。
• 项目尚未披露攻击何时开始、可能受影响的服务器数量，或资金是否已经被盗。

管理员可通过官方 BTCPay Server GitHub 发布页面查看最新发布信息。

为什么这对比特币支付基础设施很重要

BTCPay Server 之所以受欢迎，是因为它允许商户接受比特币支付，而无需依赖托管型支付处理商。这种模式与加密货币最初的理念高度一致：自我托管、抗审查以及直接结算。

但自托管也意味着自行负责。

一个 BTCPay Server 实例可能会连接到：

• Bitcoin Core 或其他链上后端
• 闪电网络节点
• 商户控制面板
• API 集成
• 热钱包
• 网店和会计工具

如果攻击者获得特权访问，后果可能不仅限于网页界面。根据具体配置，暴露的凭据可能允许篡改发票、访问后端、与闪电节点交互，或从热钱包转移资金。

这起事件提醒我们，加密支付基础设施不仅仅是一个网站，它往往还连接着实时流动性。

BTCPay Server 管理员的立即行动

如果你正在运营 BTCPay Server，优先顺序应当是先控制风险，再进行调查。

1. 升级到 BTCPay Server 2.4.2

请尽快将你的实例更新到 2.4.2 版本。升级后，不要假设流程已经成功完成。请登录并确认服务器页脚显示的是新版本。

如果你使用 Docker 部署，请按照项目官方的升级指南操作，详见 BTCPay Server 文档。

2. 如果无法立即修补，就关闭服务器

如果你无法马上升级，就先将服务器下线，直到可以完成升级为止。在正在被主动利用的情况下仍让暴露的实例在线，会带来不必要的风险。

对于公开可访问、与店铺结账系统集成，或连接到 Lightning 后端的服务器，这一点尤其重要。

3. 轮换 Lightning Network Macaroon

BTCPay Server 已明确建议用户替换可能已泄露的 macaroon。在 Lightning 基础设施中，macaroon 是由 LND 及相关服务使用的认证令牌，用于控制访问权限。

如果 macaroon 泄露，攻击者可能能够执行该凭证所允许的操作。根据权限范围不同，这可能会非常敏感。

在适用的情况下，运维人员应重新创建 macaroons.db 文件，并更新其他 Lightning Network 后端的认证字符串。关于 LND 如何使用这些凭证的背景信息，请参阅官方的 Lightning Labs macaroon 文档。

4. 将任何热链上钱包中的资金转出

如果你直接在 BTCPay Server 中创建了热链上钱包，请立即将资金转移到一个新的安全钱包中。

热钱包便于自动化支付流程、退款和商户运营，但它也暴露于服务器端风险之下。如果服务器可能已经遭到入侵，应将该钱包视为潜在不安全。

转移资金后，请使用全新的凭证和干净的配置重新创建该钱包。

5. 检查日志和访问模式

在完成补丁修复和凭证轮换后，管理员应检查以下内容：

• 最近的登录活动
• API 密钥使用情况
• 商店设置变更
• 新用户或权限变更
• 异常的发票活动
• Lightning 节点访问日志
• 外发交易
• Web 服务器访问日志

即使看起来没有资金丢失，攻击者也可能已经建立了持久化机制，或为日后使用而收集了凭证。

更大的安全启示：热钱包必须严格限额

这一漏洞凸显了加密资产运维中最重要的设计原则之一：尽量减少暴露给在线系统的资产价值。

支付服务器不应持有超过短期运营所需的资金。商家和企业应考虑采用分层钱包策略：

• 热钱包仅用于较小的运营余额。
• 定期将超额资金转入冷存储。
• 将收款与长期金库存储分离。
• 将 API 密钥和 Lightning 凭证的权限限制在最小必要范围内。
• 备份应离线保存，并设置访问控制。
• 在真正发生紧急情况之前先测试事件响应流程。

在加密世界中，软件维护与资产安全之间的界限非常模糊。一次被遗漏的服务器更新，可能就会演变成一次钱包安全事件。

为什么攻击者在 2025 年行动得更快

这起事件的时间点符合数字资产行业的更广泛趋势。安全研究人员和攻击者正越来越多地使用 AI 辅助工具来审查代码、识别可疑模式，并自动化漏洞发现。

对于防御者而言，AI 可以加速审计，并帮助开源项目更早发现漏洞。对于攻击者而言，同类工具也能缩短扫描仓库、生成利用假设以及大规模测试易受攻击部署所需的时间。

这并不意味着 AI 是每一次加密攻击事件的根源。但这确实意味着，从漏洞发现到现实世界被利用之间的窗口可能正在缩短。

业界已经越来越关注自动化漏洞研究、AI 驱动的代码审查以及软件供应链风险。OWASP 安全框架 仍然是常见 Web 应用风险的有用参考，而加密团队还必须同时考虑钱包密钥、节点凭证、智能合约权限以及支付基础设施。

对于 Bitcoin 和 Lightning 运维人员来说，教训很直接：补丁部署延迟正变得更加危险。

面向加密支付运营方的实用安全检查清单

如果你的业务通过自托管基础设施接受 Bitcoin 或 Lightning 支付，请考虑采用以下基础控制措施：

• 启用新安全更新的自动监控。
• 订阅官方项目公告。
• 在可能的情况下，通过 VPN 或 IP 白名单限制管理员面板访问。
• 使用强且唯一的管理员凭据。
• 按固定周期轮换 API 密钥和 macaroon。
• 将热钱包余额与资金库中的资产分开。
• 确保服务器备份经过加密并完成测试。
• 所有集成都应采用最小权限访问原则。
• 保持书面的事件响应计划。
• 将长期资产存放在离线或由硬件支持的自托管环境中。

这些措施无法消除所有风险，但当漏洞出现时，它们可以缩小影响范围。

OneKey 在更安全的资金管理架构中的作用

对于商家和加密团队来说，BTCPay Server 可以是一个强大的工具，既能接受比特币支付，又无需放弃支付主权。然而，支付服务器属于在线系统，不能把它们当作长期保险库来使用。

OneKey 硬件钱包旨在帮助用户将私钥保存在离线状态，因此它是将资金库资产与热支付基础设施分开存放的实用选择。在这样的架构中，BTCPay Server 可以处理日常支付操作，而较大规模的余额则可定期转入由硬件支持的自托管环境中。

这种分离很重要。当服务器端漏洞出现时，目标应当是只让有限的运营资金面临风险，而不是整个资金库。

总结

BTCPay Server 漏洞是一个严肃的提醒：自托管比特币基础设施需要持续维护。运营者应立即升级到 2.4.2 版本，轮换凭据，重新创建已暴露的钱包组件，并将资金从任何可能已被攻破的热钱包中转出。

自托管很强大，但也要求严谨的安全架构。到了 2025 年，随着攻击者拥有更强的自动化能力和 AI 辅助工具，加密货币用户和企业需要以更快的补丁更新、更小的热钱包余额，以及支付系统与长期存储之间更严格的隔离来应对。