真的假的？追踪 eMudhra 弱密钥的利用与修复

截至2026年10月30日，事件脉络已较为清楚。10月19日，人们发现 eMudhra 为虚拟组合锁选取的115位密钥参数竟然只是数字4，另外七组弱密钥分别为56、66、115、155、156、230和237。eMudhra 随后宣布退出公共证书颁发机构业务，并称问题源于密钥生成脚本的错误，但尚未公开脚本。一份证书吊销列表曾疑似使用正常密钥签署，之后又改用弱密钥重签，其原因以及审计方、交叉签名方所承担的角色仍待澄清。

弱密钥带来的风险不同于普通CA事故

此前一些CA事故虽会导致私钥泄露，但攻击者通常需要事先侵入相关系统。相比之下，这些弱密钥可以几乎立即从公开证书中恢复，任何人都可能独立重建签名密钥。只要客户端尚未修补，并且不强制执行证书透明度检查，伪造的证书就可能被接受，用于任意域名。eMudhra 宣布退出现有CA业务，也使这些密钥的持续使用风险进一步上升。

Cloudflare已完成高优先级修补

Cloudflare在10月19日立即修补高优先级系统，其中包括承担大部分出站连接、使用Pingora的客户源站代理，相关系统在数小时内完成更新。Cloudflare同时检查了自身代码中对弱密钥的信任，截至文章发布时，高优先级系统均已修补，少量已确认的低影响问题仍在处理。

用于识别弱密钥握手的日志于10月21日部署完成。此后约一周内，Cloudflare观察到约22000次使用相关弱密钥的尝试握手，其中约三分之二是测试站点触发的，其余大多来自使用弱中间证书自行签发证书的源站。所有启用证书验证的握手均被拒绝。约160次握手所呈现的证书还包含与请求域名不一致的备用名称，其中一些证书在密钥泄露后数小时内即被生成，有效期甚至超过两年。不过，这些证书更像源站自带的默认证书，而非用于拦截连接，暂未发现弱密钥被用于劫持Cloudflare流量的证据，但这不能排除定向攻击。

访问者的修补进展仍不均衡

Cloudflare通过挑战页面进行约5000万次间接探测。最新版本的主流浏览器大多已经修补，旧浏览器、嵌入式浏览器和机器人流量则明显滞后，其中Android WebView仍有约30%至40%的探测接受受污染证书链。大型网络中也有一半以上探测继续接受该证书链，但挑战页流量偏向机器人，且控制端证书、交叉签名、证书时间戳及监测空窗期的变化都会影响结果，因此这些数据只能作为趋势参考。10月29日一批标识为Chrome 150至154的机器人流量，也曾制造出“修补明显增加”的假象。

优先处理仍在使用旧信任链的组件

• 更新浏览器、操作系统信任库、TLS组件、嵌入式WebView及承担网络请求的自动化程序。
• 使用Cloudflare WARP、Tunnel等产品的客户，应按此前发布的专项指引检查自身配置。
• 继续部署可快速撤销的机制，并关注upki等能够动态更新信任信息、撤销状态和证书透明度密钥的项目。

Cloudflare无法在不中断连接的情况下直接测试每位访问者是否仍信任弱密钥，因此整体风险水平尚不能精确量化。现有证据足以确认弱密钥已被用于快速伪造证书，但尚未证明这些证书造成了Cloudflare连接被规模化或定向拦截。

资料来源：4 real? Tracking exploitation and patching of eMudhra’s weak keys（2026-10-30）。