先说结论：这不是一段有问题的代码
2026 年 10 月，Oracle 发布带外安全警示，编号 CVE-2026-91403，涉及 Java 的 JSSE（Java 安全套接字扩展），CVSS 评分 9.1。很多人第一反应是“Java 又出高危漏洞了”，但这次的根源不太一样：问题不在某段代码写错了，而在一家证书机构的密钥生成出了错。
本文只讲事件原委与修复方法，不涉及任何利用细节。
事件原委：8 张中级 CA 证书的私钥弱得离谱
证书机构 eMudhra 在 2025 年 4 月 30 日的一次密钥生成脚本出错，导致它签发的 8 张中级 CA 证书的私钥全部落在 256 以下的整数范围里，最小的一个甚至是 4。正常情况下，私钥应当是足够大的随机数，暴力推导在计算上不可行；而这么小的私钥，理论上可以在极短时间内被推导出来。
一旦私钥被推导出来，持有它的人就可以签发“看起来合法”的服务器证书。配合中间人位置（比如攻击者能拦截或篡改你与服务器之间的流量），就有可能冒充服务器，实施窃听或篡改。这就是这个漏洞的完整攻击前提：需要私钥推导加上中间人位置，不是隔着互联网直接打一台服务器。
影响范围：信任这些 CA 的客户端
受影响的是信任这 8 张 eMudhra 中级 CA 证书的 Java 客户端，具体表现为 JSSE 在校验服务器证书时可能接受伪造证书。你的服务端是不是 Java 写的并不重要，关键看你的 Java 程序作为客户端去连接外部 HTTPS 服务时，信任库里是否包含这些证书。
两种修复路径
- 升级 JDK：升到带 .0.2 后缀的修复版本，例如 21.0.13.0.2（其它 LTS 分支也有对应的 .0.2 版本）。升级后，JDK 不再信任这些有问题的证书。
- 屏蔽证书：暂时无法升级时，可以在 JDK 的安全配置里用 blocked.certs 机制屏蔽这批证书，效果等同于不信任它们。
判断自己是否需要处理：先看 JDK 版本，再看信任库与业务调用的证书链里是否出现 eMudhra 的中级 CA；不确定的，升级是最省事的办法。
后续进展：换发与退出
事件披露后，主流浏览器厂商陆续封禁了这批证书，eMudhra 撤销了相关证书，并于 2026 年 10 月 22 日宣布退出全球 SSL/TLS 证书业务，为受影响客户免费换发其它机构的证书。据公开报道，约 3 万张证书受到波及。截至目前，公开报道中暂未见在野利用的确认消息，但这不改变修复结论：信任基础一旦动摇，修是唯一正确的选择。
总结一句话：CVE-2026-91403 的教训不在代码，而在信任链——证书机构的密钥生成失误可以传导成整个生态的风险，修复靠升级 JDK 或屏蔽证书，别无他法。