Teku 和 Besu 在 eMudhra 事件后更新了各自的 Docker 镜像，因为薄弱的证书密钥给连接外部服务的软件带来了风险，其中也包括一些以太坊验证者部署。

• Teku 26.10.3 和 Besu 26.10.2 在 Docker 镜像中移除了受影响的证书信任，原因是 eMudhra 事件。
• Teku 表示，默认主网节点不受影响，实际暴露程度取决于 HTTPS 连接以及运营者使用的 Java 运行时。
• 披露的风险涉及被冒充的服务和验证者操作，Teku 的通知中没有报告被利用的情况。

对运营者来说，眼下最直接的问题是：在连接其他服务时，自己的软件是否会接受伪造证书。答案取决于所使用的连接和 Java 安装，因此客户端更新并不意味着每个验证者都面临相同风险。

Teku 和 Besu 更新 Docker 镜像

以太坊客户端团队已经发布更新，以修复一个始于区块链之外的证书问题。相关变更涉及软件如何判断远程服务是否真实。

Teku 26.10.3 和 Besu 26.10.2 从其 Docker 镜像中移除了对受影响证书根的信任。此次发布源于与证书颁发机构 eMudhra 相关的弱密钥被发现。

对于验证者运营者而言，问题在于攻击者冒充软件所连接的服务。根据该服务的角色不同，伪造响应可能打乱职责，或影响某些区块费用的支付去向。

但这并不意味着每个以太坊验证者都暴露在风险之下。Teku 的安全通知称，默认主网节点不受影响，而且目前没有报告被利用的情况。

差别在于安装方式。使用外部 HTTPS 服务的运营者，需要检查那些完全本地化组件部署中未必存在的连接。

这些更新适用于特定安装环境。补丁后的 Docker 镜像包含了容器内打包的运行时修改，而从归档文件安装的软件则可能使用运营者另外提供的 Java。

这起事件影响的是验证者周边的基础设施，而以太坊的共识规则并未改变。

证书问题为何会演变成安全风险？

证书帮助软件判断自己是否连接到了预期中的服务。受信任的证书颁发机构会为服务器证书所对应的身份提供背书。

这种机制在 HTTPS 网站中很常见，但在不通过浏览器通信的应用中同样适用。后台服务也可能依赖这些身份校验。

证书颁发机构可能在受信任根证书之下使用中间证书。与这些中间证书相关的私钥必须保持安全，因为它们可以被用来签发更多证书。

在这起事件中，问题并不只是有人拿到了服务器的普通登录信息。受影响的中间密钥可以从已经公开的信息中恢复出来。

Go 安全团队的说明称，这一弱点允许在微秒级别恢复私钥。其描述还指出，攻击者随后可以为自己并不控制的域名创建证书。

如果某个易受攻击的应用认为该证书最终仍可追溯到它信任的机构，就可能接受它。这样一来，伪造身份就可能通过原本用于拒绝冒充者的检查。

不过，攻击者仍然需要某种方式拦截或重定向受害者的连接。弱密钥并不会自动让他们出现在每个用户与每台服务器之间。

这一条件缩小了攻击发生的方式，但并不能让证书失效变得无害。只要软件把冒充者当作真实端点，网络拦截就会变得更危险。

Kudelski Security 的研究审视了受影响的证书层级。问题在于，软件可能接受由攻击者能够复现的密钥签发的证书。

eMudhra 将弱密钥归因于处理错误

eMudhra 的事件声明称，一名研究人员在 10 月 17 日报告了 8 个弱中间密钥。公司在次日吊销了这 8 个密钥。

公司表示，这些中间证书是在 2025 年 4 月 30 日的一次密钥仪式中生成的。按照公司的说法，存在缺陷的 wrap 和 unwrap 步骤在原本强密钥之外又生成了弱副本。

公司称使用了经过认证的硬件安全模块。其解释将故障归因于周边流程中的某一步，而不是归因于缺少这类设备。

公司还表示，其中 7 个中间证书从未用于生产环境，剩余的 1 个也尚未签发证书。公司称此次事件没有造成基础设施被入侵或数据泄露。

这些说法解释了 eMudhra 对其内部运作的描述。但软件供应商仍需应对另一种可能性：其他方可能利用可恢复的密钥。

证书系统不能只依赖原始运营方承诺不再签发任何内容。一旦别人也能复现某个签名密钥，这种保证就不再能控制所有可能被创建的证书。

因此，响应措施已经超出了生成密钥的那家公司。浏览器厂商、操作系统供应商和编程语言团队都需要考虑其用户的软件会接受什么。

这些修复会通过不同更新传递给用户。浏览器可能收到阻断名单，而另一个独立的 Java 应用仍可能继续使用旧的受信任证书集。

弱密钥和接受该密钥的应用是同一问题的两个不同部分。吊销证书解决的是机构记录层面的问题，而客户端还需要一种可靠方式来识别自己应该拒绝受影响的信任路径。

外部服务给验证者带来不同风险

以太坊节点由承担不同职责的软件组成。以太坊客户端文档区分了执行客户端和共识客户端：前者处理交易执行和状态，后者遵循权益证明共识。

验证者软件则增加了提议区块和对链进行证明的职责。运营者可以在本地运行这些组件，也可以通过外部服务连接其中一部分。

Teku 是共识客户端，Besu 是执行客户端。两者都使用 Java，这也是为什么运行时的证书信任与它们的发布相关。

本地机器之外的服务会为这种安排增加一道身份校验。软件需要确认响应请求的端点就是预期中的提供方。

例如，运营者可能使用远程签名服务，而不是把签名操作保留在同一个进程中。也有人可能依赖外部端点提供数据或区块构建服务。

冒充者能造成多大损害，取决于该服务被允许做什么。只接收监控数据的服务，与参与签名决策的信息提供服务，风险并不相同。

网络路径同样重要。穿越公共基础设施的连接，与仅限同一主机或受严格控制的私有网络中的组件相比，拦截机会不同。

私有网络并不能让所有故障都不可能发生，但它可以减少攻击者获得干扰流量所需位置的机会。

因此，仅凭客户端名称并不能判断是否暴露。相同的软件可以部署在使用不同端点、信任库和访问控制的环境中。

真正需要回答的问题是：哪一条连接通过了受影响的路径接受证书。一旦明确这一点，运营者就能评估被冒充的服务在验证者运作中本应拥有多大权限。

为什么 Docker 镜像和归档安装不同？

Docker 镜像会把应用及其运行所需环境一起打包，其中可能包括 Java 运行时以及该运行时所信任的证书。

更新主机上的 Java，并不会自动替换现有镜像中的 Java。容器仍可能继续使用自己打包的文件。

这就是客户端发布说明会特别提到 Docker 变更的原因。Teku 的说明称，其 Eclipse Temurin 基础镜像当时尚未包含相关移除，因此客户端镜像直接做了修改。

Besu 的发布说明同样表示，其证书移除适用于 Docker 镜像，并明确要求归档安装用户检查自己提供的 Java 发行版。

归档安装会把这项责任留给运营者。以太坊客户端可能已经更新，但其单独的运行时仍可能包含旧证书存储。

反过来，在维护过程中也会出现类似区别。替换主机运行时会影响使用该运行时的进程，但不会影响另一个使用不同 Java 路径的安装。

Oracle 的事件指导建议用户更新受影响的运行时，或遵循其文档中给出的替代方案。它还要求重启正在运行的实例，并分别考虑每个独立安装。

这使得正在运行的进程比下载到的更新更重要。服务器可以包含已打补丁的文件，但旧进程仍会继续运行，直到被替换或重启。

自定义证书存储又增加了另一种变化。某个组织可能使用的是为自身服务维护的证书库，而不只是 Java 默认提供的证书库。

实际任务是找出客户端真正使用了什么。安装方式、运行时位置和信任配置共同决定了已发布的修复是否已经到达需要它的那条连接。

吊销检查在不同应用中的差异

吊销意味着证书不应再被接受。但这并不保证每个应用在建立连接前都会检查最新的吊销信息。

不同应用获取这些信息的方式也不同。有些会查询在线服务，有些使用供应商提供的阻断名单，还有些主要依赖本地信任库中的证书。

Go 团队的响应说明了为什么运行时供应商可能需要直接介入。该团队在 10 月 19 日启动了紧急安全发布，并表示在收到通知后约 7.5 小时内就提供了修补版本。

这一动作阻断了使用相关 Go 验证行为的应用所涉及的受影响证书路径。Java 用户则需要通过自己的运行时和信任设置获得保护。

Teku 的通知称，Java 默认不会检查吊销。这也是为什么即便 eMudhra 已经吊销了这些中间证书，仍有必要在本地移除信任。

根证书移除和中间证书阻断也可能作用于不同层面。前者拒绝某一条特定的受损路径，后者则可以拒绝通向被移除根证书的更广泛证书链。

正确的实现属于供应商和维护应用的组织。若临时采取一种禁用身份校验的做法，只会移除保护，而不是解决信任问题。

合法服务也可能需要调整。如果它们的证书依赖于客户端现在拒绝的路径，那么服务方就必须提供可接受的替代方案，而不是指望用户恢复不安全的信任。

这也解释了为什么一次证书事件可能会持续数天。发现可能是即时的，但保护会通过浏览器、打包应用和私有基础设施的不同发布与维护流程逐步到位。

对于验证者运营者来说，关键结果是相关连接是否已经拒绝不受信任的身份。软件生态中其他地方的吊销公告，并不能证明其节点进程已经达到了这一结果。

奖励和验证者质押是否以同样方式暴露？

验证者的质押、签名职责和费用支付彼此相关，但它们受不同机制约束。影响其中一项的问题，不应自动被描述为对所有这些内容的控制。

以太坊质押文档说明，验证者通过履行职责获得奖励，并会因离线或可证明的不当行为而受到惩罚。签名权限和提现权限在系统中扮演不同角色。

证书密钥属于用于连接的身份系统。它不是验证者的私有签名密钥，也不会直接泄露管理已质押 ETH 提现的凭证。

不过，被冒充的服务仍可能影响验证者的行为。其影响取决于该服务处理哪些请求或响应，以及还保留了哪些额外检查。

区块提议包含执行相关支付的费用接收方。若某条路径能够修改提议或配置，就可能产生后果，而不必控制整个质押。

签名服务又提出了另一组问题，因为它参与授权验证者行为。它自身的保护措施，包括对请求的限制以及防止冲突签名的保障，都会影响攻击者能做到什么程度。

服务中断导致的职责遗漏也是一种可能后果。即便没有成功转移任何支付，攻击者只要阻止正确响应，也可能减少奖励。

这些结果的财务影响并不相同。错失提议区块机会、普通离线惩罚和削减处罚，不能混为一谈。

客户端公告描述的是在受影响配置下可能出现的后果，并没有证明每个运营者都遭遇了这些后果，也没有证明有相应数量的 ETH 被盗。

对于使用质押服务商的持有者来说，真正相关的是服务商的实际部署。管理了多少 ETH，并不能说明其运营者使用了哪些远程服务或证书库。

验证者也依赖以太坊之外的软件

以太坊网络规则只是运营者依赖的一部分。硬件、运行时、托管、配置和外部服务都会影响验证者是否能正确履行职责。

证书颁发机构位于以太坊协议之外，但当验证者软件依赖它来识别服务时，它的故障就会变得相关。仅凭这一点，就足以把一个通用互联网安全问题带入质押基础设施。

客户端多样性仍然有价值，因为不同实现可以减少对单一代码库的依赖。但这并不意味着每个依赖项都是独立的。

两个客户端可以使用同一个编程语言运行时。不同运营者也可能使用同一家托管服务商、签名服务或区块构建基础设施。

这些共享组件会在以太坊软件本身不同的情况下，形成共同暴露面。因此，要理解部署情况，不能只看客户端品牌数量。

外包也会带来权衡。专用签名服务可能改善密钥保护方式，但也会让与该服务的认证连接变得更加重要。

本地运行也有自己的维护要求。把组件放在同一台机器上可以减少部分网络暴露，但运营者仍需管理软件更新以及对那台机器的访问。

这起事件并不会自动给出一种在所有情况下都最安全的架构。它说明的是，必须理解并维护每一条连接周边的职责。

这种区别对普通 ETH 用户也很重要。节点基础设施中的证书补丁，并不意味着每个钱包都必须转移资金，也不意味着以太坊账户余额发生了变化。

相关行动属于受影响的软件运营者。他们才有能力识别所涉及的运行时、端点和信任设置，然后把供应商的相关指导应用到正在建立这些连接的系统上。

运营者需要应用并检查更新

这些发布为运营者提供了从受支持的 Docker 镜像中移除受影响信任路径的方法。归档用户则需要根据各自 Java 供应商的指导，处理单独的运行时工作。

补丁可用只是流程的第一步。更新后的环境还需要真正运行，并保持预期配置和服务正常工作。

对于服务提供方来说，由新近被拒绝的证书引发的中断，可能需要在端点更换证书。恢复服务时应保留身份校验，而不是绕过它。

后续披露可能进一步细化影响。运营者也许会识别出某个接受了受影响证书链的配置，或者报告涉及特定服务的事件。

就目前而言，Teku 的通知报告没有被利用，并区分了默认主网使用与受影响的外部连接。这是描述当前以太坊暴露面的最清晰依据。

受影响的运营者有理由更新。任何财务损失都取决于攻击者冒充了哪个服务、是否拦截了流量，以及验证者允许该服务做什么。

需要关注什么

• 客户端更新：关注 Teku 和 Besu 的发布，并确认已运行修补后的版本。
• Java 证书：查看每个安装所使用的 Java 运行时和证书库的供应商指导。
• 外部连接：审查指向远程签名、数据和区块构建服务的 HTTPS 链接。
• 安全通知：留意客户端团队和 Java 供应商发布的确认攻击或进一步说明。

常见问题

eMudhra 事件是什么？

这起事件涉及与证书颁发机构 eMudhra 的中间证书相关的弱私钥。研究人员发现，这些密钥可以从公开信息中恢复，从而可能让其他人创建自己并不控制的域名证书。信任受影响证书路径的软件可能会接受这种伪造身份。攻击者仍然需要某种方式拦截或重定向连接，才能冒充目标服务。

以太坊共识是否失败了？

没有。报告中的问题涉及软件如何检查外部服务的身份，而不是以太坊在区块链上达成一致的规则。客户端更新改变的是受影响软件环境中的证书信任。某些验证者部署如果遭遇外部服务被冒充，仍可能面临运营风险。这种可能性取决于连接和服务角色，并不意味着以太坊共识规则被破坏。

哪些客户端被更新了？

Teku 26.10.3 和 Besu 26.10.2 修改了它们的 Docker 镜像，以移除受影响的证书信任。Teku 是共识客户端，Besu 是执行客户端，两者都使用 Java。安装方式很重要，因为该变更适用于这些镜像中提供的环境。安装客户端归档并自行提供 Java 运行时的运营者，需要单独查看该运行时的指导。

所有验证者都会受影响吗？

不会。Teku 的通知称，默认主网节点不受影响。风险取决于某个部署是否进行了相关外部 HTTPS 连接，以及其证书检查是否接受受影响的信任路径。不同运营者可以在不同服务、Java 版本和证书库下运行同一客户端。因此，客户端名称或质押的 ETH 数量，并不能说明某个特定验证者是否暴露。

Docker 更新能覆盖所有安装方式吗？

不能。补丁后的 Docker 镜像会更新该镜像内打包的环境，但归档安装可能使用运营者另外提供的 Java。其他容器或服务也可能有自己的运行时。运营者需要识别正在运行的进程使用的是哪种安装方式，并遵循其供应商说明。服务器上的已打补丁文件，并不能保护仍在旧环境中运行的进程。

是否已确认被利用？

在本文所述时间点，Teku 的通知没有报告被利用。相关披露描述的是一个弱点及其可能后果，而不是证明攻击者已经将其用于验证者。讨论损失时，这一区别很重要。存在一条冒充服务的可能路径，并不等于签名职责被操纵、费用支付被转移或质押 ETH 被盗。

验证者存款会自动暴露吗？

不会。证书签名密钥不同于验证者签名密钥，也不同于控制提现的凭证。恢复受影响的证书密钥，并不会自动泄露提取质押 ETH 所需的密钥。被冒充的服务仍可能打乱职责或影响验证者使用的信息，具体取决于部署方式。应针对该服务评估可能后果，而不是把它视为对整个存款的自动访问。

运营者应该怎么做？

运营者应遵循相关 Teku 或 Besu 发布说明，以及其 Java 发行版的指导。需要识别每个受影响进程所使用的运行时和证书库，包括容器内提供的部分。应用建议更新后，应确认更新后的服务正在运行，并且所需连接仍可正常工作。为了恢复失败连接而禁用证书检查，会移除这些检查本应提供的保护。