2026年10月21日披露的java cve-2026-91403属于jsse模块安全问题，oracle给出的cvss 3.1评分为9.1，根源是8张已失陷的中间ca证书。处理这个漏洞需要更新实际运行的jdk或对应证书信任数据，只修改spring boot、tomcat、maven这类上层依赖不会生效。
CVE-2026-91403 为什么会影响Java HTTPS连接
JSSE是Java内置的安全网络连接模块，应用发起HTTPS请求、通过TLS连接数据库或调用其他加密接口时，通常会依赖证书链校验对端身份。哪怕证书链的格式完全合法，链上的签发机构也可能早已失陷不再可信。
中间CA的密钥一旦泄露失陷，应用若仍信任相关证书链，攻击者便可能借此冒充通信对端，破坏传输数据的保密性和完整性。OpenJDK 2026年10月21日公告明确本次漏洞关联8张失陷中间CA证书，排查范围要落到实际的证书验证路径上，不能直接把这个漏洞等同于所有Java服务都存在通用远程代码执行问题。
Oracle的风险矩阵标注该漏洞可通过网络利用、无需身份认证，这只是描述利用的前置条件，不代表访问任意Java对外服务就能直接入侵，也不能替代对单个业务系统实际调用逻辑的针对性分析。
哪些JDK版本需要处理
Oracle独立安全警报列出的Java SE受影响版本包括8u511、8u511-perf、11.0.33、17.0.21、21.0.13、25.0.5、27.0.1，还涉及部分GraalVM产品。OpenJDK公告覆盖的受影响版本包含8u512，以及对应维护分支的更早版本。不同厂商发布的JDK构建号要单独对照，不能通用一张升级清单。
上述所有版本均为受影响版本，绝非已经修复的版本，哪怕刚做完季度安全更新的环境，也要确认所用JDK的供应商是否已经同步推送本次独立警报的修复内容。挑选升级包时，要同时核对供应商、版本分支、完整构建号和该CVE对应的修复说明。
修复前先找到应用实际使用的Java
同一台服务器上可能同时装了系统默认JDK、应用自带JRE、多个容器运行时，终端敲java命令调用的程序，和systemd、Tomcat、容器进程启动时加载的Java很可能不是同一个文件。
<code class="bash"># 在目标主机或对应容器内检查当前命令的运行时
java -version
java -XshowSettings:properties -version
# Linux：将数字替换成目标 Java 进程的真实 PID
java_pid=12345
readlink "/proc/${java_pid}/exe"</code>
查看当前命令对应的JDK路径可以读取属性java.home，Linux系统下查看指定进程的JDK路径可以读/proc/PID/exe文件。容器场景要进入容器命名空间单独检查，如果进程对应的路径后面标了(deleted)，说明磁盘上的旧JDK文件已经被替换，但之前启动的进程还在沿用旧文件，需要重启进程或替换运行实例。
独立JDK：优先升级修复构建，也可临时更新官方阻断清单
如果你的JDK是通过压缩包、安装器或者应用捆绑方式手动部署的独立版本，优先选用JDK供应商已经发布的修复构建。暂时没法直接升级的情况下，可以按OpenJDK公告给出的方法，更新$JDK_HOME/lib/security路径下的blocked.certs文件，JDK 8的同位置下对应的文件名为blacklisted.certs。
公告提供了Unix类系统的阻断文件和Windows版本的阻断文件，你要从官方公告给出的链接下载对应文件，替换时要保留之前手动添加的自定义阻断条目，所有独立部署的运行时都要单独处理。如果下载时遇到403、404错误或者返回HTML页面，立刻停止替换操作，改用供应商发布的完整修复安装包。
这份阻断清单和cacerts是完全独立的两个文件，前者用来拦截不可信证书，后者保存该信任库中的受信任证书。不要把刚下载的阻断文件直接覆盖到cacerts上，也不要随便从第三方论坛复制几个证书指纹就当成完整更新包。所有修改完成后要重启对应的Java实例，避免JVM继续沿用之前已经初始化的旧证书验证状态。
Linux发行版、Homebrew和容器的差异化处理
OpenJDK公告说明，Debian、Ubuntu、RHEL、Fedora等主流发行版自带的OpenJDK通常会调用操作系统层面的全局证书库，更新系统证书就能覆盖大部分场景的信任校验，不过Homebrew和FreeBSD上的OpenJDK包需要直接更新Java对应的软件包。这套处理方式只适用于对应发行版的默认安装版本，不能套用到手动解压部署的独立JDK上。
如果业务代码手动通过javax.net.ssl.trustStore参数指定了独立的自定义证书库，或者自己实现了证书验证逻辑，就要单独检查这部分配置。容器里的JDK和证书文件要么在镜像内要么通过挂载引入，应检查实际镜像和挂载配置，确认更新进入容器使用的信任数据；需要时重建镜像并替换旧实例。
没法及时升级时，怎么启用证书吊销检查
OpenJDK公告还给出了TLS应用启用吊销检查的JVM启动参数示例，你要把示例里的JDK绝对路径、JAR文件名和原有启动参数，替换成自己业务的实际配置：
<code class="bash">/opt/your-jdk/bin/java \ -Dcom.sun.net.ssl.checkRevocation=true \ -Dcom.sun.security.enableCRLDP=true \ -jar /srv/your-app/app.jar</code>
这些参数要加到业务服务正式的启动命令里，单独在终端执行一次参数命令不会改变已经运行的JVM状态。证书吊销检查本身依赖网络获取吊销信息，可能会增加连接延迟，你要提前评估服务到相关吊销信息站点的连通性。如果业务代码本身就绕过了标准的证书信任校验逻辑，这些参数也没法补齐所有验证规则。
更新后出现PKIX错误或者TLS握手失败怎么排查
先定位报错对应的进程，确认它用的JDK路径、当前加载的证书链和自定义truststore配置。如果是正常业务用到的证书链刚好经过本次列入黑名单的失陷中间CA，联系对应的证书服务商更换成合法的可信证书链，不要用“信任全部证书”、关闭主机名校验、直接删除阻断条目这类方式强行恢复连接。
普通可信站点能正常完成HTTPS连接，只能说明当前对应连接的配置可用，不能证明这个漏洞已经完全修复。判断漏洞是否处理完成的依据，是你所用JDK供应商的修复说明、证书信任数据的官方来源，以及业务实际走的证书验证路径，Java应用的证书信任逻辑取决于这些具体条件，和业务本身是否已经开启HTTPS没有直接对等关系。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
