Java JSSE 漏洞解读：CVE-2026-91403 影响面、原理与修复（CVSS 9.1）- 惊觉

事件背景：季度补丁发布次日，紧急安全警报随之而来

2026 年 10 月 21 日，Oracle 发布紧急安全警报，披露 Java 安全组件 JSSE 存在一个 CVSS 评分为 9.1（Critical） 的漏洞：CVE-2026-91403。该漏洞无需认证、无需用户交互，可通过网络远程利用。

更值得关注的是时间点：10 月 20 日 Oracle 刚发布季度补丁（Critical Patch Update），Java 8/11/17/21/25/27 全线更新；结果第二天，20 日刚发布的版本——8u511、11.0.33、17.0.21、21.0.13、25.0.5、27.0.1——全部出现在 21 日紧急警报的受影响列表中。
在这里插入图片描述

也就是说，如果你在 20 日把生产环境的 JDK 升到了最新版本，21 日就被告知：这个"最新版本"仍在受影响范围内。原因在于该漏洞不在季度补丁计划内，属于"计划外事故"，Oracle 只能在补丁发布第二天单独发布紧急警报补救。

核心结论：漏洞的发现速度，已经接近甚至超过厂商的补丁节奏。

一、漏洞定位：JSSE 与 HTTPS 证书信任链

JSSE（Java Secure Socket Extension）是 Java 平台负责 HTTPS/TLS 通信的安全组件。调用外部 HTTPS 接口、支付网关、第三方 API 时，走的就是它。

HTTPS 的安全性建立在证书信任链上：

Java 程序收到一个证书 → 检查它是否由可信机构签发 → 一路向上查到根证书 → 根证书预装在 JDK 的"信任库"（cacerts）中。链条完整、根证书可信，连接才被放行。

这次漏洞的根源，就出在这条信任链上。

二、漏洞原理：信任链如何被攻破

根据 Oracle 公告，本次问题源于 Java 信任库中预置的 eMudhra（emSign）公司的 8 个中间 CA 证书：这批证书在 2025 年生成密钥时，私钥强度严重不足，其中一个私钥的值仅为个位数（4）。

私钥强度不足意味着攻击者可能掌握或推算出这批弱私钥，进而：

以 emSign 的名义为任意域名签发"合法"SSL 证书；
在网络中间实施中间人攻击（DNS 劫持、路由污染等）；
由于证书链完整、根证书在 Java 信任库中，Java 程序校验通过；
客户端以为在与真实服务端通信，实际上每条 HTTPS 请求都被中间人读取或篡改。

浏览器等运行时已陆续将相关证书列入黑名单，但 JDK 自带信任库（cacerts）中的证书需要单独处理。

三、影响面自查

该漏洞无需账号、无需权限、无需点击，只要网络可达即可利用，以下场景风险较高：

对外发起 HTTPS 调用的服务：支付网关、短信服务、第三方 API、微信/支付宝回调对接；
CI/CD 拉取依赖：构建机连接 Maven 中央仓库、Docker Hub，若被中间人，依赖可能被替换为恶意版本；
客户端/桌面应用：Java Web Start 等加载不可信代码的场景。

受影响版本（Oracle 官方公告）：

产品	受影响版本
Java SE	8u511、11.0.33、17.0.21、21.0.13、25.0.5、27.0.1
GraalVM for JDK	17.0.21、21.0.13
GraalVM Enterprise Edition	21.3.20

Oracle官方安全警报公告（CVE-2026-91403）

注意：Oracle 明确指出，更早的未支持版本很可能同样受影响。不在列表中的老版本反而更危险——因为它们连补丁都不会再有。

此外，操作系统全局证书库与 JDK 信任库属于同一条信任链。curl、wget、Python、Nginx 反向代理、包管理器等均使用系统证书库。只升级 JDK 而不清理系统证书，等于只封堵了一半攻击面。

四、修复方案：四步走

第 1 步：确认 JDK 版本

java -version

对照上述受影响表，若命中则继续。

第 2 步：升级 JDK（首选）

升级到官方修复版本，新版本通过内置黑名单精准拦截受影响证书：

独立安装的 OpenJDK / Temurin / Oracle JDK：直接升级到修复版本；
系统包管理器安装：升级 JDK 的同时同步更新系统证书库，例如 Ubuntu：

sudo apt install --only-upgrade ca-certificates ca-certificates-java

第 3 步：临时缓解——替换黑名单文件

若暂时无法升级，可替换 Oracle 提供的更新后黑名单文件（JDK 8 为 blacklisted.certs，JDK 9+ 为 blocked.certs）：

# JDK 8：覆盖
$JAVA_HOME/jre/lib/security/blacklisted.certs

# JDK 9+：覆盖
$JAVA_HOME/lib/security/blocked.certs

替换后必须重启所有 Java 进程，信任库在 JVM 启动时加载，不重启等于没改。

第 4 步：JVM 参数加固（补充防御）

开启证书吊销检查，作为额外防御层：

-Dcom.sun.net.ssl.checkRevocation=true -Dcom.sun.security.enableCRLDP=true

三个高频坑

只修 JDK 不修系统证书：curl/Python/Nginx 仍在裸奔，两条信任链必须同步处理；
修改后不重启进程：信任库是 JVM 启动时加载的，不重启不生效；
使用 -Djavax.net.ssl.trustStore 自定义证书库：自定义信任库不会跟随 JDK 自动更新，必须单独检查清理。

五、延伸思考：AI 时代的漏洞节奏

本次事件与近期 PHP 引擎级漏洞有共同背景——AI 辅助漏洞挖掘已明显提速：

Anthropic 的 Mythos 模型上线一个月，协助合作伙伴发现超 1 万个漏洞；
其自研扫描在 1000 个开源项目中挖掘出 2.3 万个漏洞，单周输出超过全球 CVE 月均总量；
过去资深工程师挖掘一个高危漏洞平均需要 3-7 天，现在被压缩到分钟级甚至几十秒。

漏洞发现速度已显著快于厂商补丁节奏。对开发者而言，建议：

版本管理认真对待：不要长期停留在"稳定但古老"的版本，跟随 LTS 安全基线；
依赖审计常态化：将依赖扫描（如 OWASP Dependency-Check）纳入日常流程；
补丁窗口要快：看到安全通告当天处理，不要拖延。

作者：蜗牛工具箱，Java 开发/培训，目前全职独立开发者。专注 AI 工具实战与技术事件拆解，欢迎关注同名公众号，也欢迎评论区聊聊。

转载自 CSDN-专业IT技术社区

原文链接：https://blog.csdn.net/Li_Ya_Fei/article/details/169069619

Java JSSE 漏洞解读：CVE-2026-91403 影响面、原理与修复（CVSS 9.1）

目录