首页 > 资讯 > eMudhra证书漏洞引发以太坊客户端安全

印度凭证机构eMudhra私钥漏洞波及以太坊，Teku与Besu紧急升级

2026-10-30 09:52:46 佚名

简介印度 CA 机构 eMudhra 私钥存在熵值不足漏洞，可被逆向破解,以太坊 Teku、Besu 客户端紧急更新，移除相关信任凭证，漏洞存在中间人攻击风险，部分节点还需手动处理系统证书库，下面一起来看看正文内容吧

印度数字凭证机构 eMudhra 爆出严重私钥生成缺陷，连带以太坊两大主流客户端 Teku 与 Besu 先后发布安全版本，负责权益证明（PoS）共识层运行的验证者客户端Teku 26.10.3于北京时间周二正式上线；处理链上交易撮合与执行层逻辑的客户端Besu 26.10.2亦于北京时间周一完成推送。开发者在新版本和 Docker 镜像中移除、不再信任所有关联 eMudhra 的证书。下文梳理漏洞成因、攻击路径、节点影响范围以及事件带来的底层信任体系反思。

溯源该起安全事件的演进链条，技术隐患早在10月17日便被密码学研究团队捕获。监测表明，eMudhra旗下八个中继凭证机构（Intermediate CA）在生成底层私钥的过程中存在严重的伪随机数熵值不足问题。基于这一低级数学漏洞，外部攻击者能够直接通过完全公开的数字证书逆向计算出对应的根私钥。持有该私钥的未授权方有能力任意签发伪造凭证，并骗过未加设防的客户端软件。尽管全球主流互联网浏览器在事发次日便迅速封禁了相关证书，且eMudhra随即宣布吊销受损证书并计划彻底退出凭证签发业务，但链上基础设施的防护盲区却未能同步消除。

Teku与Besu之所以在此次事件中受到牵连，根源在于两大客户端均深度基于Java语言开发构建。在默认环境配置下，Java运行库并不会主动发起针对公钥证书吊销列表（CRL）或在线状态（OCSP）的联网比对。这一底层特异性导致各大网页浏览器早已剔除的非法凭证，仍在以太坊节点的预设容器镜像中处于被完全信任的活跃状态。

验证节点出块奖励面临篡改威胁

在以太坊现行的PoS共识机制中，验证者节点负责质押代币、参与打包验证并捕获优先交易打包费（Priority Fees）。为了降低安全单点暴露风险，不少专业验证节点选择通过局域网或公网与外部独立组件协同运行，并依托传输层安全（TLS）证书确认交互链路的真实身份。

若攻击者利用泄露的证书私钥实施DNS投毒或路由劫持，便能在验证节点与远端依赖项之间伪装中间人身份。Consensys Diligence安全团队在威胁建模评估中明确提示了潜在的经济攻击路径：

篡改区块提议费率接收地址：遭受中间人劫持的验证节点可能在伪造指令误导下，在提议新区块时将本应归属于自身的矿工小费重定向至攻击者设立的链上地址；
攻破外部签名者（External Signer）鉴权：作为物理隔离私钥的安全模块，外部签名机制若被伪造证书所欺瞒，攻击者即可借此套取有效签名凭据，进而对节点的区块奖励分派参数实施篡改。

针对该风险敞口，Teku开发团队在随后的安全备忘录中说明，主网环境下采用标准单机配置、未外接网络签名组件的默认节点并未受到实际波及，无需采取被动防御措施，且全网尚未监控到针对该漏洞的实际攻击案例。

公钥体系盲区倒逼信任供应链重构

值得注意的是，此次安全加固在实操运维层面并非全自动化覆盖。对于直接在物理机或独立虚拟机环境中裸机运行编译程序、而非调用Docker容器化镜像的节点运营商而言，仅将Teku或Besu升级至最新版本并不能化解风险。由于以太坊应用程序的更新无法穿透修改操作系统底层Java环境的根证书受信列表，相关技术人员必须手动进入底层环境更新CA证书库。更为棘手的是，仍滞留在Java 26运行环境的节点已无法获得官方补丁推送，必须强制切换适配至维护周期内的Java25长期支持版（LTS）。

从深层次的网络互联视角审视，这一事件打破了区块链节点天然免疫传统网络威胁的技术神话。以太坊共识层虽然依托去中心化账本消除单一权威中心，但节点在网络通信与身份校验链路中，依然深度绑定在传统互联网的公开密钥基础设施（PKI）底座之上。一旦中心化证书体系的上游产生熵值脆弱性，去中心化客户端同样会被动承接安全传导。

面向后续的基础设施安全演进，两大核心变量值得持续跟踪：其一，去中心化节点客户端团队是否会重新审视Java环境的证书吊销核查配置，推动内置动态黑名单与严格OCSP校验成为出厂标配；其二，在eMudhra被动退出国际认证业务后，全球范围内仍为加密基础设施提供通信加密的区域性CA机构，是否会迎来一轮彻底的密码学合规清查。