CVE-2026-91403 排查指南：Java JSSE 信任链漏洞的根因、影响范围和修复步骤
信息来源：Oracle Security Alert Advisory（2026-10-21 发布）、OpenJDK 官方 ops.java/emudhra 处置指引页（2026-10-22 更新）。本文只整理已公开的事实和官方修复路径，不推测攻击场景，不提供利用代码。
目录
- 这个漏洞到底出了什么问题
- 根因：eMudhra 的 8 组中间 CA 私钥为什么能被破解
- 受影响版本和版本自查方法
- 两条修复路径：升级 JDK 和手动覆盖 blocked.certs
- 你的 Spring Boot 项目需不需要额外处理
- 这次事件里容易踩的几个认知误区
这个漏洞到底出了什么问题
10 月 21 日，Oracle 发布了一份 Security Alert（不是常规的季度补丁公告），披露了编号 CVE-2026-91403 的高危漏洞，CVSS 3.1 评分 9.1。
漏洞出在 Java 的 JSSE（Java Secure Socket Extension）组件上。JSSE 是 Java 处理 TLS/SSL 加密通信的核心库，你的 Spring Boot 应用通过 HTTPS 调外部接口、通过 TLS 连数据库、甚至 gRPC 通信，底层都走 JSSE。
问题的本质不是"Java 代码有 bug 可以被远程执行"，而是信任链被污染。Java 的 cacerts 信任库中仍然信任了 eMudhra 相关的中间 CA 证书，而这些 CA 的私钥已经泄露。这意味着攻击者理论上可以用泄露的私钥伪造一张看起来合法的 TLS 证书，你的 Java 程序在建立 HTTPS 连接时不会拒绝它。
换句话说：该拦的假身份，拦不住了。
这和常见的"远程代码执行"漏洞不同。攻击者不能直接在你的服务器上跑代码，但如果他能处于网络中间人位置（比如控制你到目标服务器之间的某个路由节点），就可以用伪造证书劫持你的 Java 应用的 TLS 连接，读取或篡改加密通道里的数据。
根因：eMudhra 的 8 组中间 CA 私钥为什么能被破解
这次漏洞的源头不在 Oracle 的代码里，而在印度数字证书机构 eMudhra 的一次严重密钥生成事故。
10 月 17 日，安全研究人员 Scott Helme 向 Google、Mozilla、Apple、Microsoft 和 eMudhra 报告：eMudhra 的 8 组中间 CA 私钥存在严重安全缺陷。这 8 张证书中有 6 张用于 TLS 加密通信，另外 2 张用于代码签名。涉及的密钥还包含由 Sectigo 签发的交叉签名证书。
问题出在算法参数上。这些证书使用 P-384 椭圆曲线加密算法，但对应的私钥数值竟然全部小于 256。P-384 曲线的私钥应该是一个接近 384 位的大整数，私钥值小于 256 意味着密钥空间被极度压缩，攻击者可以在极短时间内暴力破解出私钥。
eMudhra 声称 8 个受影响的中间 CA 中只有 1 张真正进入过生产环境，且未签发过客户证书。但 Mozilla 和 Chrome 仍然在 10 月 20 日分别通过 NSS 更新和 CRLSet 拦截，取消了对 eMudhra 根证书的信任。10 月 22 日，eMudhra 董事会决定退出全球 TLS 证书业务。
Oracle 在 10 月 21 日发布的 Security Alert 中，核心修复动作就是：让 Java 的 JSSE 不再信任 eMudhra 相关的中间 CA 证书。
受影响版本和版本自查方法
根据 Oracle 公告，以下版本受影响：
| 产品 | 受影响版本 |
|---|---|
| Oracle Java SE | 8u511、8u511-perf、11.0.33、17.0.21、21.0.13、25.0.5、27.0.1 |
| Oracle GraalVM for JDK | 17.0.21、21.0.13 |
| Oracle GraalVM Enterprise Edition | 21.3.20 |
Oracle 同时提醒，更早的版本也可能存在风险。
注意一个关键时间点：Oracle 在 10 月 20 日刚发布了季度关键补丁更新（CPU），为 Java SE 修复了 55 个安全漏洞。但 CVE-2026-91403 是第二天单独披露的，即使你在 10 月 20 日打了季度补丁，仍然受这个漏洞影响。
自查当前 JDK 版本：
bash
java -version输出中关注版本号。如果你用的是 Oracle JDK，对照上表确认是否在受影响范围内。如果你用的是 OpenJDK 发行版（如 Adoptium/Temurin、Amazon Corretto、Azul Zulu），需要到对应发行版的官网确认他们是否已经合入了这次修复。
我本地跑的是 OpenJDK 11.0.32.1（Temurin），在受影响版本列表里（11.0.33 及之前），需要升级。
两条修复路径：升级 JDK 和手动覆盖 blocked.certs
路径一：升级到修复版本（推荐）
Oracle 已经为受支持的产品提供了补丁。最直接的修复方式是升级到不受影响的 JDK 版本。对于 OpenJDK 用户，关注你的发行版团队是否已经发布了包含此次修复的更新。
升级后，JSSE 的信任库会自动移除对 eMudhra 相关中间 CA 的信任。你不需要手动修改 cacerts 文件。
路径二：手动覆盖 blocked.certs（临时缓解）
如果暂时无法升级 JDK，OpenJDK 官方给出了一个手动缓解方案。在 ops.java/emudhra 页面上，Oracle 提供了对应各操作系统的 blocked.certs 文件下载。
操作步骤：
- 找到你当前 JDK 的安全属性目录。通常在
$JAVA_HOME/conf/security/（JDK 9+）或$JAVA_HOME/jre/lib/security/（JDK 8）。 - 下载对应操作系统的
blocked.certs文件，覆盖到该目录下。JDK 8 用户注意：文件名需要改为blacklisted.certs。 - 确认
java.security文件中存在以下配置项且未被注释：
properties
# JDK 9+
jdk.certpath.disabledAlgorithms=...
# 确认 blocked.certs 被加载（通常默认启用）- 重启你的 Java 应用。
手动覆盖 blocked.certs 的效果是：JSSE 在做证书链验证时，会检查证书是否在黑名单中。eMudhra 相关的中间 CA 指纹被加入黑名单后，即使它们还在 cacerts 信任库里，证书链验证也会失败。
这个方案是临时措施。长期仍然建议升级 JDK，因为 blocked.certs 只覆盖已知的坏证书，不会修复 JSSE 中可能存在的其他相关问题。
你的 Spring Boot 项目需不需要额外处理
对于大多数 Spring Boot 项目，修复 JDK 就够了，不需要改业务代码。但有几个场景值得额外检查：
自定义 TrustStore 的项目。 如果你的 Spring Boot 应用没有使用 JDK 默认的 cacerts，而是通过 javax.net.ssl.trustStore 系统属性指定了自定义的信任库文件，那么 JDK 自带的 blocked.certs 可能不会自动应用到你的自定义 TrustStore。你需要检查自定义信任库中是否包含 eMudhra 相关证书，如果有，手动删除对应条目。
使用了自定义 SSLContext 的代码。 有些项目为了实现双向 TLS（mTLS）或跳过证书验证（测试环境常见），会自己构建 SSLContext 和 TrustManager。这种情况下 blocked.certs 的黑名单检查可能不生效。排查方法是在代码中搜索 SSLContext.getInstance、X509TrustManager、setHostnameVerifier 等关键字。
Docker 和 K8s 环境。 如果你的 Java 应用跑在容器里，需要确认容器镜像中的 JDK 版本。很多基础镜像（如 eclipse-temurin:17-jdk）会跟随上游更新，但如果你锁定了具体小版本号或者用了自定义镜像，需要重新构建。
Spring Boot 本身不需要特殊配置。spring.ssl.bundle 相关配置（Spring Boot 3.1+ 引入）走的是 JDK 的标准 JSSE 路径，JDK 修复后自动生效。
这次事件里容易踩的几个认知误区
误区一："我的应用只在内网跑，不受影响。" 如果你的内网服务通过 HTTPS 连接外部 API、数据库或消息队列，且攻击者能够处于你的内网和外部服务之间的网络路径上，伪造证书就可以劫持这条连接。内网不等于安全区。
误区二："我昨天刚打了季度补丁，已经安全了。" CVE-2026-91403 是在 10 月 20 日季度补丁发布之后、10 月 21 日单独披露的 Security Alert。季度补丁不包含这次修复。 需要单独确认是否已经应用了针对此 CVE 的更新。
误区三："这个漏洞能让攻击者远程执行代码。" 不能。 CVE-2026-91403 影响的是机密性和完整性，不影响可用性。攻击者不能直接在你的服务器上执行代码。风险在于 TLS 通道被劫持后，传输中的数据（请求参数、响应体、认证令牌）可能被读取或篡改。
误区四："eMudhra 说没签发过客户证书，所以没事。" eMudhra 的原话是 8 个受影响的中间 CA 中只有 1 个进入过生产环境且未签发客户证书。但根证书被浏览器和 JDK 取消信任后，依赖这个根证书链的所有证书都需要迁移，不管它们本身有没有被泄露。 这是一个信任体系层面的问题，不只是"有没有被利用"的问题。
误区五："我用的 Let's Encrypt / DigiCert，跟 eMudhra 无关。" 你的终端证书签发者和这次漏洞没有直接关系。但问题出在 Java 的 JSSE 验证证书链时，是否会错误地信任一条经过 eMudhra 中间 CA 的伪造链。即使你自己的证书是 Let's Encrypt 签的，如果你的 Java 应用访问的某个下游服务的证书链被伪造到 eMudhra 链上，JSSE 在修复前不会拒绝它。
参考资料