通过 Docker 更新了 Core Lightning?如何检查安全修复是否确实存在
核心要点
- 当您的 Core Lightning 节点在启动时打印 v26.06.7 时,并不能证明该版本中的安全修复程序实际上正在运行。
- 根据该项目,任何固定到 v26.06.6 或更早版本的人都不会受到影响。
- 如果您运行签名者变体,请使用相应的 -vls 标签。

当您的 Core Lightning 节点在启动时打印 v26.06.7 时,并不能证明该版本中的安全修复程序实际上正在运行。任何在 2026 年 8 月 28 日 16:04 UTC 至 9 月 1 日期间通过 Docker 拉取更新的人都可能正在运行一个正确报告自身的映像,但仍然不包含修复程序。可靠的证据是图像摘要,而不是版本输出。本文将引导您完成所需的检查以及之后要做什么。自我们 8 月 30 日的文章以来,情况在两个地方发生了变化:有问题的 Docker 窗口现已记录在发行说明中,而源代码的禁运已于 9 月 11 日到期。两者都改变了您作为操作员需要做的事情。 Core Lightning(以前称为 c-lightning)是 Lightning 协议的三种广泛使用的实现之一,用 C 编写并在 ElementsProject/lightning 存储库中维护。这里的实现只是一个独立的程序,它应用与竞争程序相同的网络规则,但有自己的代码,因此有自己的错误。闪电网络本身是比特币区块链之上的第二层:双方共同将资金锁定在支付通道中,然后在他们之间结算任意数量的支付,而无需将每一笔都写入链中。无论谁运行这样的节点,都拥有这些锁定资金的钥匙。这就是问题的严重性:节点软件中的错误会直接影响属于您且没有其他人监视的比特币。自我保管意味着承担责任,但这并不意味着存储密钥就结束了。它还涵盖了使用该密钥的软件是否与您认为已安装的状态匹配的问题。如果您希望在不运行服务器服务的情况下持有资产,您可以在我们的硬件钱包比较中找到适合的设备。然而,对于闪电节点来说,没有办法保持运行软件的最新状态。版本 26.06.7 的 Docker 镜像出了什么问题 版本 26.06.7 于 2026 年 8 月 28 日作为维护版本发布。该项目的公告很简洁:这是一个修复了过去三周向团队报告的已确认漏洞的点版本。单点版本是仅包含修复且不包含新功能的临时版本。对于 Docker 用户来说,这个过程中出现了一些问题。随后,发行说明中添加了一个部分,直接指出了错误:在 UTC 时间 8 月 28 日 16:04 到 9 月 1 日之间,四个标签提供的图像在启动时报告了 v26.06.7,但不包含该版本的修复。受影响的标签是 v26.06.7 、latest 、v26.06.7-vls 和latest-vls 。该项目本身指出了原因:自动构建过程从占位符标签发布了图像。它们已被替换,并且任何标签都不再引用错误的清单。清单是定义组成容器映像的各个部分的描述符文件。然而,任何仍然在本地持有错误版本的人都不会注意到此更正:您下载的内容会保留在您的计算机上。一分即可彻底清除一组操作员。根据该项目,任何固定到 v26.06.6 或更早版本的人都不会受到影响。该问题仅影响那些在所述窗口期间拉取 26.06.7 或最新版本的用户。为什么启动时的版本号并不能证明补丁级别 显而易见的检查也是无用的。打印运行版本的调用仅读出在构建时写入程序的字符串。如果该字符串来自占位符标记,则未修补的程序会如实报告所传递的数字,并且不会告诉您有关实际代码的任何信息。这是我们自己 8 月 30 日文章中尴尬的部分:我们让您检查版本。对于受影响窗口内的 Docker 操作员来说,该检查毫无价值,当时没有任何方法可以判断。因此,这是后续行动,因此从这里开始进行不同的检查。摘要是唯一标识容器镜像的校验值。它是清单上的加密散列,因此也是图像的实际内容上的加密散列。诸如“最新”之类的标签是一个移动指针,可以指向今天的一张图像和明天的另一张图像。摘要不能做到这一点:更改内容的单个字节,值就会更改。因此,它是唯一能告诉您实际运行情况的信息。两批货物从外观上看是一样的:只有检查值显示哪一件是完好无损的。三个问题就可以解决这个问题。第一:您是否获得了作为容器的软件?从发布页面安装 tarball 的任何人都不会受到影响,因为这些档案从一开始就是正确的。第二:您的下载是否落在 8 月 28 日 16:04 UTC 至 9 月 1 日之间的窗口内?发行说明没有给出该窗口结束的确切时间,因此仍然存在一定程度的模糊性,如果有疑问,最好经常检查一次。第三:您使用了四个标签之一吗?任何不确定所有三个问题的人都可以进行摘要检查。无论您何时以及如何获取图像,该检查都会花费您一个命令并最终回答问题。该版本的镜像有三个平台: linux/amd64 、 linux/arm64 和 linux/arm/v7 。第三个有一个与小型单板计算机操作员有关的特性:没有 linux/arm/v7 的发行版 tarball。该平台的二进制文件是单独编译的,并且不包含在未签名的清单中。因此,任何研究该架构的人一开始的证据链都比其他两种架构要弱。最重要的是,根据该项目,这些图像既没有出处,也没有 SBOM 证明,这意味着没有机器可读的来源证明。
如何检查 Lightning 节点的镜像摘要 发行说明中指定的命令会读出本地保存的镜像的摘要。它看起来像这样: docker image inform --format '{{index .RepoDigests 0}}' elementsproject/lightningd:v26.06.7 输出是您必须比较的值。该项目为校正后的图像指定了两个目标值。对于标签 v26.06.7 和最新版本,它读取 sha256:0421a5f0d1b2e1ad639edfa17d777816040e3850d91bae7f2d32186d9c1e6da4 。对于 v26.06.7-vls 和latest-vls 下的签名者变体,它读取 sha256:6a5e05c13a65613f8c0fe3830c60248a6724e7206c1c23dd26ac2e98a3e72c1f 。关于运行它的两个注意事项。该命令仅查询您的本地存储,不下载任何内容,也不进行任何更改。它指的是你给它的标签:如果你使用latest,则使用latest;如果您运行签名者变体,请使用相应的 -vls 标签。如果打印的值与目标值逐字符匹配,则您已完成并运行更正的构建。重要的是比较全长。快速浏览第一个和最后四个字符是不够的,因为这正是人类在有疑问时挥手示意“足够接近”的部分。将两个值相邻复制并机械地比较它们,例如将目标值写入文件并对照它检查输出。摘要不匹配:如何拉出校正后的图像 如果值不同,补救措施并不引人注目。对于实际使用的每个标签,再次拉取图像: docker pull elementsproject/lightningd:v26.06.7 docker pull elementsproject/lightningd:latest 然后使用与上面相同的命令再次检查摘要。只有当新值与目标值匹配时,您才会重新启动容器,以便运行的进程实际上使用新的映像。拉取本身不会取代正在运行的容器;您的节点将继续以旧状态运行,直到重新启动。任何通过 Compose 文件或协调器运行容器的人都应该确保配置不会回退到缓存的本地状态。最简洁的方法是随后固定经过验证的摘要本身,而不是移动标签。这样,同样的混淆就不会再发生在您身上,因为引用绑定到内容而不是名称。重新启动时可能会出现边缘的一项更改:在当前映像中,Core Lightning 安装到 /usr/bin 和 /usr/libexec/c-lightning ,而早期映像使用 /usr/local 。包含来自旧位置的符号链接,因此硬连线路径继续有效。任何使用绝对路径运行自己的脚本的人仍然应该检查一下它们。 VLS 操作员:为什么签名者必须匹配节点版本 VLS 代表验证闪电签名者,表示一个单独的签名服务,该服务保存节点的密钥并在发布之前根据自己的规则检查每个签名。要点是:即使节点受到损害,攻击者也无法说服签名者进行任意支付。对于这些操作员来说,迁移到 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 拒绝启动。这虽然不方便,但实际上是良性的:服务根本不启动,而是以半匹配状态运行。在升级期间设置变量并且签名者保持可达状态。任何误读消息并将节点回滚到旧版本以使签名者运行的人都会准确地撤消这一切的修复。随着禁运期满,两周以来一直保密的事情现在已经公开。禁运已经结束:这对未打补丁的节点意味着什么 该项目故意隐瞒了该版本的源代码。原因在发行说明中:补丁显示了它更改的代码,而延迟是为了降低攻击者在网络更新之前对修复程序进行逆向工程并利用它们的可能性。那个时期已经结束了。现在,发行说明中的内容是这样的:“禁运已经结束。此版本的源代码发布于 2026-09-11T11:42Z。”此后,v26.06.7 标签指向构建二进制文件的提交,并且源存档附加到该版本。对于作为操作员的您来说,这会扭转风险状况。直到9月11日,一个未打补丁的节点还受到攻击者不知道细节的保护。这种保护已经消失,没有任何东西可以替代它,因为从那时起这些变化就一直是公开可读的。任何今天还没有跟上的人都在运行其漏洞已记录并可供任何人检查的软件。该项目还声明不再支持 26.06.7 之前的版本。值得注意的是,可以从发布元数据本身读取:amd64 校验和的签名文件直到 2026 年 9 月 12 日 06:02 UTC 才上传。在此之前任何想要验证签名的人都找不到适合此架构的签名。相比之下,校验和文件本身自 8 月 28 日起就已可用。
