Teku与Besu发布更新 修复涉及eMudhra八个CA的以太坊(ETH)验证者漏洞

Teku 26.10.3与Besu 26.10.2修复证书漏洞

Teku团队于星期二发布26.10.3版本客户端,Besu则在星期一跟进26.10.2版本,两项更新都将与印度eMudhra相关的证书从信任列表及Docker镜像中移除。变更已记录在Teku 26.10.3与Besu 26.10.2的官方发布说明中。此次修复封堵了一条攻击路径:在高风险配置下,攻击者本可悄悄将部分验证者奖励导向自己控制的地址。共识规则未被破坏,Teku团队也记录称,迄今未发现任何利用行为。以太坊(ETH)价格本身从未依赖这些证书,但验证者赚取的费用和奖励确实流经受影响的工具链。

验证者是向以太坊权益证明链质押以保障安全的计算机,负责提议区块并收取费用作为回报。部分验证者需要通过互联网与外部服务通信,并依赖数字证书确认对端服务的真实性。暴露点正是这套外围设施,而非协议本身。

研究人员于10月17日发现,eMudhra八个中间证书颁发机构的私钥在生成时随机性不足。由于证书本身是公开文件,私钥可以从证书中直接推算出来,持钥者随后可伪造证书,未被修补的软件会将其当作真实证书接受。浏览器率先行动,停止接受这些证书。eMudhra次日撤销了相关证书,并随后表示将彻底退出证书业务。该弱点最早由Consensys Diligence发现,这家安全机构也是Teku审计的合作方。预打包的Docker镜像是许多运营商采用的部署方式,也是两个客户端共同的受影响分发渠道。更广的以太坊客户端生态在验证者工具上依赖Java运行,这一细节决定了暴露范围和修复方式。

为何默认主网节点无需处理

Teku和Besu均以Java编写,而Java默认不检查证书是否已被吊销。因此即便浏览器早已弃用相关证书,Teku的Docker镜像仍在接受它们,这也是修复通过镜像而非单纯Java更新交付的原因。Teku团队随发布一起发布的公告按顺序描述了攻击过程:位于验证者与其所连服务之间的攻击者可以冒充该服务,受骗的验证者随后可能提议一个把费用支付给攻击者地址的区块。风险最高的配置涉及外部签名者,即单独持有验证者密钥的服务:伪造的外部签名者可能交出改变奖励去向的签名。

Java默认设置的这一缺口解释了各方响应的先后顺序。浏览器会检查吊销状态,因此一天之内就切断了这些证书;基于Java的以太坊工具不会,客户端团队于是直接重建Docker镜像,将eMudhra从信任集合中移除,而不等待运行时层面的修复。对多数运营商而言,情况更简单:在主网上以默认配置运行的Teku节点不受影响,无需任何操作,现有记录也显示没有奖励被盗。补救方式因部署而异。使用预打包Docker镜像的运营商应拉取最新的Teku或Besu版本。直接在自家机器上运行软件的人则面临更多工作,因为更新以太坊客户端不会触及宿主机上的Java安装,新镜像也不会修复宿主机层面的Java。最棘手的情况属于仍在使用Java 26的人。该版本已终止支持,不会再有修补版,迁移到Java 25是这些运营商唯一的出路。

这一事件更像是一次运维层面的插曲,而非协议层危机。共识层安然无恙,真正面临风险的人群也很窄:使用外部签名者、非默认网络路径或陈旧Java安装的运营商。不过对任何在权衡以太坊节点运维成本的人而言,这仍是一项需要列入的开支项,因为客户端周围的运行时环境需要按自己的节奏打补丁。两个修补版本现已在各自代码仓库上线,每位运营商今天就能执行修复。两次发布落地以来,尚无对该漏洞严重性的独立评估,客户端团队的公告目前仍是唯一的公开判断。