BTC核心闪电网络节点启动时显示 v26.06.7 并不等于安全补丁已生效
当你的 Core Lightning 节点在启动时打印出版本信息 v26.06.7，这并不能证明该版本中的安全修复程序正在实际运行。在 2026 年 8 月 28 日 16:04 UTC 至 9 月 1 日期间通过 Docker 进行更新的任何人，可能都在运行一个镜像，该镜像在启动时正确报告自身版本，但并未包含相应的安全修复。可靠的证据是镜像摘要（Image Digest），而非版本输出。本文将指导你完成必要的检查步骤，以及后续应采取的措施。
自我们 8 月 30 日的文章发布以来，情况在两个方面发生了变化：故障 Docker 窗口现已记录在发布说明中，且源代码的保密期已于 9 月 11 日解除。这两点变化都影响了作为运营者你需要采取的行动。
什么是 Core Lightning 以及为何此次更新与你有关
Core Lightning（前身为 c-lightning）是闪电协议三大广泛使用的实现之一，使用 C 语言编写，并在 ElementsProject/lightning 仓库中维护。“实现”在此处指的只是一个独立程序，它应用与其他竞争程序相同的网络规则，但拥有自己的代码，因此也有其特有的漏洞。
闪电网络本身建立在比特币区块链之上：双方共同将资金锁定在一个支付通道中，然后在彼此之间结算任意数量的支付，而无需将每一笔支付都写入区块链。运行此类节点的人自己持有这些锁定资金的密钥。这就是问题严重的根本原因：节点软件中的漏洞会直接影响属于你且无人监管的比特币资产。
自我托管意味着承担责任，这不仅限于存储密钥，还包括确保使用该密钥的软件是否处于你所认为已安装的状态。如果你宁愿不运行服务器服务而持有资产，你可以在我们的硬件钱包比较中找到相关设备。但对于闪电网络节点而言，保持软件更新是不可避免的。
v26.06.7 版本 Docker 镜像出了什么问题
v26.06.7 于 2026 年 8 月 28 日发布，作为一个维护版本。项目的公告非常简练：这是一个点发布（point release），旨在修复在过去三周内报告给团队的已确认漏洞。点发布是指仅包含修复内容而无新功能的中间版本。
对于 Docker 用户来说，流程中出现了一些错误。随后发布的说明中增加了一节，明确指出错误所在：在 8 月 28 日 16:04 UTC 至 9 月 1 日期间，四个标签提供了在启动时报告 v26.06.7 但不包含该版本修复程序的镜像。受影响的标签包括 v26.06.7、latest、v26.06.7-vls 和 latest-vls。
项目自行指出了原因：自动化构建过程发布了来自占位符标签的镜像。这些问题镜像已被替换，错误的清单（manifests）不再被任何标签引用。清单是定义容器镜像由哪些单独部分组成的描述文件。然而，任何仍本地持有错误版本的人都不会察觉到此修正：你当时下载的内容仍保留在你的机器上。
有一点可以完全排除一组运营者的风险。根据项目方的说法，任何固定为 v26.06.6 或更早版本的节点从未受到影响。问题仅出现在那些在上述窗口期内拉取了 26.06.7 或 latest 的用户身上。
两个外观相同的外部交付物：只有检查值能显示哪一个完好无损。
为什么启动时的版本号不是补丁级别的证明
显而易见的检查也是无用的。调用打印运行版本只是读取在构建时写入程序的字符串。如果该字符串来自占位符标签，那么未修补的程序会诚实地报告它收到的数字，而不会告诉你关于实际代码的任何信息。
这是我们 8 月 30 日文章尴尬之处：那时我们让你检查版本。对于受影响窗口内的 Docker 运营者来说，该检查毫无价值，当时也无法辨别。因此有了这篇后续文章，以及从此开始的不同的检查方法。
摘要（Digest）是唯一标识容器镜像的检查值。它是针对清单的加密哈希，因此也是针对镜像实际内容的哈希。像 latest 这样的标签是一个移动的指针，今天可以指向一个镜像，明天指向另一个。摘要则不能这样做：更改内容的一个字节，值就会改变。因此，它是唯一能让你知道真正运行内容的信息。
你是否受影响？窗口期、标签及三个平台
三个问题即可确定情况。第一：你是否以容器形式获取了软件？任何从发布页面安装 tarball 存档的人从未受到影响，因为这些存档从一开始就是正确的。第二：你的下载是否落在 8 月 28 日 16:04 UTC 至 9 月 1 日的窗口期内？发布说明未给出该窗口结束的确切时间，因此仍有一定模糊性，如有疑问，多检查一次总是更好的。第三：你是否使用了上述四个标签之一？
对以上三个问题中任何一个不确定的人，都应始终运行摘要检查。该检查只需一条命令，无论何时或以何种方式获取镜像，都能彻底回答问题。
此版本的镜像有三个平台：linux/amd64、linux/arm64 和 linux/arm/v7。第三个平台有一个特殊性，涉及单板计算机的小型运营者：没有 linux/arm/v7 的发布 tarball。该平台二进制文件是单独编译的，不受签名清单覆盖。因此，在此架构上工作的人从一开始就比另外两个平台拥有较弱的证据链。此外，根据项目方说法，这些镜像既没有来源证明，也没有 SBOM（软件物料清单）证明，意味着没有机器可读的来源证明。
如何检查你闪电网络节点的镜像摘要
发布说明中命名的命令用于读取本地持有的镜像摘要。如下所示：
docker image inspect --format '{{index .RepoDigests 0}}' elementsproject/lightningd:v26.06.7
输出的是你需要比较的值。项目方列出了修正后镜像的两个目标值。对于标签 v26.06.7 和 latest，其值为 sha256:0421a5f0d1b2e1ad639edfa17d777816040e3850d91bae7f2d32186d9c1e6da4。对于签名者变体下的 v26.06.7-vls 和 latest-vls，其值为 sha256:6a5e05c13a65613f8c0fe3830c60248a6724e7206c1c23dd26ac2e98a3e72c1f。
运行时有两点注意事项。该命令仅查询你的本地存储，不下载任何内容也不更改任何内容。并且它引用你提供的标签：如果你使用 latest，请使用 latest；如果你运行签名者变体，请使用相应的 -vl 标签。如果打印的值与目标值逐字符匹配，你就完成了，正在运行修正后的构建。
重要的是比较完整长度。快速查看前四个和后四个字符是不够的，因为正是这部分在存疑时容易被人类误认为是“足够接近”。将两个值并排复制并进行机械比较，例如将目标值写入文件并检查输出是否符合。
摘要不匹配：如何拉取修正后的镜像
如果值不同，补救措施并不复杂。再次拉取镜像，针对你实际使用的每个标签：
docker pull elementsproject/lightningd:v26.06.7
docker pull elementsproject/lightningd:latest
然后使用与上面相同的命令再次检查摘要。只有当新值与目标值匹配时，才重启容器，以便运行的进程实际使用新镜像。单独的 pull 操作不会替换正在运行的容器；在重启之前，你的节点将继续在旧状态下运行。
任何通过 Compose 文件或编排器运行容器的人，应确保配置不会回退到缓存的本地状态。最干净的方法是在之后固定经过验证的摘要本身，而不是移动的标签。这样就不会发生第二次同样的混乱，因为引用绑定到了内容而不是名称。
重启时可能会出现边缘变化：在当前镜像中，Core Lightning 安装在 /usr/bin 和 /usr/libexec/c-lightning，而早期镜像使用 /usr/local。包含了来自旧位置的符号链接，因此硬编码路径继续有效。任何使用绝对路径运行自己脚本的人，仍应仔细检查一遍。
VLS 运营者：为何签名者必须与节点版本匹配
VLS 代表 Validating Lightning Signer（验证闪电签名者），表示一个分离的签名服务，它持有节点的密钥并在发出签名之前根据其自身的规则检查每个签名。其目的是：即使节点被攻破，攻击者无法让签名者执行任意支付。
对于这些运营者来说，升级到 26.06.7 时有一个硬性边界。根据项目方说法，v26.06.7-vls 变体包含与 v26.06.6-vls 相同的签名者，即 VLS v0.14.0，此版本未对其进行改动。然而，签名者要求 VLS_CLN_VERSION 变量与其通信的节点匹配。如果节点运行 v26.06.7 而变量仍读取 v26.06.6，remote_hsmd_socket 将无法启动。
这很不方便，但在效果上是无害的：服务根本无法启动，而不是在半匹配状态下继续运行。在升级期间设置该变量，签名者即可保持可达。任何人如果误读消息并将节点回滚到旧版本以使签名者运行，恰恰取消了这一切的核心修复。
随着保密期解除，过去两周被掩盖的内容现在已公开。
#@0_119#@
保密期已结束：这对未打补丁的节点意味着什么
项目方故意扣留了此版本的源代码。理由在发布说明中：补丁显示了它更改的代码，延迟的目的是降低攻击者在网络更新之前逆向工程修复并利用它们的几率。
这段时间已经结束。发布说明现在明确写道：“保密期已结束。此版本的源代码已于 2026-09-11T11:42Z 发布。”
v26.06.7 标签此后一直指向构建二进制文件的提交，源代码归档也附在了发布说明中。
对于作为运营者的你来说，风险状况发生了逆转。直到 9 月 11 日，未打补丁的节点也受到保护，因为攻击者不知道细节。随着变更变得公开可读，这种保护已经消失，且没有任何替代品。至今仍未跟进的人正在运行其漏洞已被记录且任何人都可检查的软件。项目方还指出，26.06.7 之前的版本不再受支持。
值得注意的是，可从发布元数据本身读取：amd64 校验和的签名文件直到 2026 年 9 月 12 日 06:02 UTC 才上传。在此之前的任何想要验证签名的人都找不到此架构的签名。相比之下，校验和文件本身自 8 月 28 日起就已可用。
为何 --offline 临时措施不能替代更新
8 月 28 日的项目公告中包含了一个临时步骤，供无法立即更新的所有人使用。使用 --offline 标志重启会将节点与传入消息切断，从而完全 deny 攻击者以任何方式针对它。服务保持运行并处理区块链，因此它仍然可以检测通道合作伙伴的欺诈尝试。项目方写道，应在升级后移除该标志并重启节点。
此临时措施旨在用于没有公开详细信息的时期。自 9 月 11 日以来，它不再是更新的替代品，仅是覆盖你需要赶上时间的桥梁。封闭的节点不转发支付，不赚取费用，且对交易对手不可达。作为永久状态，这是昂贵的停机成本。
相同的检查例程值得应用于你自己设置中的其他构建块。如果你在节点前面放置了一个管理界面，你应该知道它在网络上是否可达；我们在 9 月 11 日描述了 Alby Hub 的这条路线。此系列漏洞的起点在我们 8 月 30 日的文章中：Core Lightning：节点运营者现在必须做什么。
未使用 Docker 安装？如何验证校验和与签名
任何从发布页面获取 tarball 的人拥有更好的证据链，但也必须走完它。每个二进制文件都由签名清单覆盖。首先检查校验和：
sha256sum -c SHA256SUMS-v26.06.7 --ignore-missing
然后是该校验和文件上的签名：
gpg --verify SHA256SUMS-v26.06.7.asc SHA256SUMS-v26.06.7
文件 SHA256SUMS-v26.06.7 覆盖 amd64 存档；arm64 有单独的文件及其自己的签名。四位项目维护者进行了签名，发布说明单独列出了他们的指纹。一个细节可以避免误报：签名可能会报告与所列不同的指纹，因为签名者使用子密钥。一旦导入主密钥，gpg --verify 会自动解决此问题，差异并非检查失败。
还有第二块更快的证据，这也是此版本真正优雅的部分。校验和文件从一开始就包含来自源代码归档 clightning-v26.06.7.zip 的一行，尽管该归档在 8 月 28 日尚未公开。由于该文件当时已签名，这意味着提前承诺了现在发布的精确字节。这使得能够在几分钟内且无需编译器地证明今天可见的源代码与八月签署的相同，且在保密期间未被篡改。
可重现构建：此版本证据链的终点
可重现构建（Reproducible build）是一种构建过程，从相同的源代码产生字节对字节的相同二进制文件。它允许第三方独立证明发布文件确实来自发布的源代码。对此版本而言，这只部分成立，项目方自己也指出了局限性。
首先，归档不是在默认优化级别下构建的。配置默认使用 -Og，而发布的二进制文件是使用 -O3 生成的。任何人检出标签并正常构建得到的文件将与校验和不匹配；必须显式传递 COPTFLAGS=-O3。其次，arm64 归档无法从此状态重建，因为所需工具不在本版本的源代码树中。这些文件仍可通过签名验证，但不能独立重现。第三，项目方指出 Fedora 重建可能会有所不同，因为那里的构建镜像每次运行都是全新更新的，不同日子进行的两个人最终可能得到不同的工具版本。
这读起来是对存在缺口的证据链的诚实描述，而非对相关人员的批评。对于作为运营者的你来说，在实践中意味着：依赖签名和校验和，并将完整重建视为专家的工作，而非维护例行公事的一部分。
此事件揭示了加密货币软件供应链的哪些问题
真正的教训在于交付环节，而非漏洞本身。错误源于自动化构建过程，该过程发布了来自占位符的镜像。没有人需要被攻击，然而一个做错了事情却声称正确的文件在那里待了好几天。
项目方自己在发布说明中命名了一个原因，解释了为何此类维护版本可能会变得更频繁：越来越多强大的 AI 模型被部署用于在开源代码中寻找潜在漏洞，这显著增加了报告的频率和速度。因此，任何运行基础设施的人都将不得不更频繁地更新，这使得如何验证更新的问题比是否执行了更新的问题更重要。
由此衍生出三个习惯，且耗时不多。将容器固定到摘要而非移动标签。每次更新后，检查内容而非标签。并记录你在何时推出了哪个版本及对应的检查值，以便在下一次建议发布时，能在几分钟内知道是否影响你。任何不愿对运行中的服务器服务投入此精力的人，应诚实地考虑更精简的托管安排是否更适合他们的日常惯例。
检查你的 Core Lightning 更新：要点总结
今天检查摘要，而非版本号。
一条命令，一项与发布说明中目标值的比较，即可回答问题。如果在过程中发现运行自己的节点变得太繁琐，我们的硬件钱包比较为你提供了纯服务器自我托管替代方案的概览。
如果值不同，重新拉取并重启。
拉取，再次检查摘要，交换容器，然后才移除 --offline 标志。对于之后在节点上以软件运行的所有内容，软件钱包比较值得一看，因为更新路线和来源证明的同一问题也适用于那里。
围绕检查值建立维护流程。
固定摘要，每次下载后验证校验和和签名，记录状态。如果你想补充通道，你会在我们的如何购买比特币概览中找到路线。
(截至 2026 年 9 月 15 日。本文不构成投资建议。价格和费用结构会发生变化；购买前请与提供商核实条款。)
主要来源：项目仓库中的 Core Lightning v26.06.7 发布说明以及 Blockstream 项目的发布公告。
交易所
交易所排行榜
24小时成交排行榜
人气排行榜
交易所比特币余额
交易所资产透明度证明
去中心化交易所
资金费率
资金费率热力图
爆仓数据
清算最大痛点
多空比
大户多空比
币安/欧易/火币大户多空比
Bitfinex杠杆多空比
ETF追踪
索拉纳ETF
瑞波币ETF
香港ETF
比特币持币公司
加密资产反转
以太坊储备
HyperLiquid钱包分析
Hyperliquid鲸鱼监控
大额转账
链上异动
比特币回报率
稳定币市值
期权分析
新闻
文章
财经日历
专题
钱包
合约计算器
账号安全
资讯收藏
自选币种
我的关注