前言
大家好，我是苏三。
这几天PHP那个漏洞闹得沸沸扬扬，很多Java开发还在群里看热闹，说"还好我们用Java"。
结果话还没说完，Java这边也炸了。
2026年10月21日，Oracle Java SE被曝出一个CVSS 9.1分 的高危漏洞，编号CVE-2026-91403 ，漏洞组件是JSSE（Java Secure Socket Extension）。
9.1分什么概念？
满分10分，7分以上就算高危，9分以上意味着远程、无需认证、低复杂度就能打。
而且JDK 8、11、17、21、25、27全线受影响。**
今天这篇文章，我就把这个漏洞的来龙去脉、底层原理、以及你该怎么处理，从头到尾给你拆解一遍。
希望对你会有所帮助。
更多项目实战在Java突击队网：susan.net.cn/project
一、这个漏洞到底有多严重？
我先把官方数据摆出来，你自己感受一下。
| 指标 | 数据 |
|---|---|
| CVE编号 | CVE-2026-91403 |
| 受影响组件 | JSSE（Java Secure Socket Extension） |
| CVSS 3.1评分 | 9.1（CRITICAL） |
| 攻击向量 | 网络（AV:N） |
| 攻击复杂度 | 低（AC:L） |
| 所需权限 | 无（PR:N） |
| 用户交互 | 无（UI:N） |
| 影响 | 机密性完全丧失、完整性完全丧失 |
数据来源：www.cve.org/CVERecord?i...
翻译成人话就是：攻击者不需要任何账号，不需要受害者点任何链接，只要你的Java应用对外提供网络服务，他就能远程打进来，读取你的数据、篡改你的数据。
JSSE是什么？
它是Java里负责TLS/SSL加密通信的核心组件。
你用的HTTPS、你连数据库的SSL连接、你调外部API的加密通道------底层全是JSSE在干活。
换句话说，这个漏洞影响的不是某个业务功能，是Java应用和外界通信的"安全通道"本身。
二、JSSE里到底出了什么事？
有些小伙伴可能会说："说了半天，到底是怎么被攻击的？"
官方披露的信息比较克制，只说"JSSE组件存在漏洞，可通过向API提供数据的Web服务利用"。
但结合漏洞的CVSS向量（AC:L、PR:N、UI:N），我们能推断出几个关键点。
第一，问题出在输入验证或状态管理上。
JSSE在处理TLS握手、证书解析、或者加密参数协商时，对某些输入的处理存在缺陷。攻击者可以构造特殊的网络数据包，触发这个缺陷。
第二，不需要证书或密钥。
攻击者不需要拥有合法的TLS证书，也不需要知道任何密钥，就能触发漏洞。这意味着攻击门槛极低。
第三，影响范围是整个通信链路。
JSSE一旦被攻破，加密通道就不再安全。攻击者可能读取明文数据，或者注入篡改后的数据。
一个类比：你家的防盗门（JSSE）本来应该挡住外人，结果门锁的某个零件设计有缺陷，小偷不需要钥匙，用一根铁丝就能捅开。而且这个门锁装在几乎所有Java应用上。
三、哪些版本受影响？你的项目中招了吗？
这是大家最关心的问题。
我把官方公布的受影响版本列出来：
| 产品线 | 受影响版本 |
|---|---|
| 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 | 21.3.20 |
数据来源
关键点：JDK 8、11、17、21、25、27全部在列。
也就是说，不管你用的是老项目还是新项目，只要在这几个版本上，都受影响。
怎么确认自己的版本？
bash
java -version如果输出里包含上面列出的版本号，比如 java version "1.8.0_511" 或者 openjdk version "21.0.13"，那就是中招了。
注意：这里列的是Oracle官方版本号。
如果你用的是OpenJDK的其他发行版（比如Temurin、Corretto、Zulu），需要去对应厂商的安全公告页确认。
通常厂商会在Oracle发布补丁后几天内跟进。
四、修复方案：现在该做什么？
4.1 立即升级JDK
Oracle已经在2026年10月20日发布了修复版本。你需要升级到以下版本之一：
| 产品线 | 修复版本 |
|---|---|
| Oracle Java SE | 8u512, 11.0.34, 17.0.22, 21.0.14, 25.0.6, 27.0.2（或更高） |
如果你用的是OpenJDK发行版，去对应厂商的下载页找最新补丁版本。
通常Oracle发布后1-3天内，Temurin、Corretto等会跟进。
升级后验证：
bash
java -version确认版本号已经变成修复版本。
4.2 如果暂时无法升级
有些团队因为兼容性问题，短期内升不了JDK。
这种情况下，可以做临时缓解：
限制JSSE暴露面：如果你的应用不对外提供TLS服务（比如只在内网跑，前面有Nginx做TLS终止），漏洞的暴露面会小很多。
但这不等于安全，内网横向移动的风险依然存在。
加强网络层监控：在WAF或IDS上，监控异常的TLS握手流量。
但这个方案治标不治本，攻击者可以变换手法。
最务实的建议 ：升级。
9.1分的漏洞，临时缓解手段都是权宜之计。
五、一张图看懂这个漏洞的影响链路
六、为什么Java的漏洞比PHP更"要命"？
PHP那个漏洞影响的是PHP应用。
Java这个漏洞影响的是Java的TLS通信层。
Java在企业里的位置太特殊了。
银行的核心交易系统、电商的订单服务、政务的数据交换平台------底层全是Java。
这些系统之间通信靠什么？
TLS。
JSSE就是TLS的Java实现。
攻击者拿到JSSE的突破口，等于拿到了所有Java应用之间加密通信的"万能钥匙"的仿制品。
这也是为什么Oracle给这个漏洞打了9.1分，而不是像之前那些Spring Boot的CVE（比如CVE-2026-40972的时序攻击，需要同网段条件）只打中等分数。
JSSE的漏洞，攻击面是网络，不需要任何前置条件。
七、顺带说一句：Spring Boot那边也不太平
如果你觉得Java SE的漏洞已经够糟了，那Spring Boot生态今年的安全状况也不容乐观。
2026年4月，Spring Boot 4.0.6修复了8个CVE，包括：
- CVE-2026-40972：DevTools远程密钥比较的时序攻击，极端情况下可导致远程代码执行
- CVE-2026-40975 ：
${random.value}使用弱伪随机数生成器，不适合用于密钥 - CVE-2026-40973：可预测的临时目录未验证所有权
还有3月份的CVE-2026-22733，Actuator CloudFoundry端点下的认证绕过，评分High。
Spring Boot的漏洞大多有条件限制 （需要DevTools、需要特定配置、需要同网段），但JSSE这个漏洞不需要任何前置条件。
这就是9.1和6.x、7.x的区别。
八、优缺点与适用场景（针对修复方案）
| 方案 | 优点 | 缺点 | 适用场景 |
|---|---|---|---|
| 立即升级JDK | 根治，无残留风险 | 需要测试兼容性 | 所有生产环境 |
| 临时限制暴露面 | 快速，不需要改代码 | 治标不治本 | 紧急过渡期 |
| WAF监控 | 有一定预警作用 | 攻击者可绕过 | 辅助手段 |
| 不处理 | 无 | 9.1分漏洞裸奔 | 不推荐 |
更多项目实战在Java突击队网：susan.net.cn/project
九、写在最后
回到最初的问题：Java也爆出了重大安全漏洞，该怎么办？
答案很直接------升级。
9.1分的CVSS评分，远程、无需认证、低复杂度。
这不是"可以等等看"的漏洞，是"今天就该处理"的漏洞。
JSSE是Java应用和外界通信的安全通道，这个通道失守，后面所有的安全措施都是建立在沙地上的。
具体操作：
java -version确认版本- 如果版本在受影响列表里，去Oracle或你用的OpenJDK发行版下载最新补丁
- 升级，回归测试，上线
- 如果暂时升不了，至少把TLS暴露面收窄，加强监控
别觉得"我的项目在内网，没事"。
内网横向移动是真实存在的攻击路径，而且JSSE的漏洞不需要攻击者先拿到什么立足点------他直接就能打你的TLS端口。
Java生态的安全，从来不是"Java本身安全"就能保证的。
JDK有漏洞，Spring Boot有漏洞，第三方依赖有漏洞。
你能做的，是保持关注、及时升级、别让自己成为那个"还在用受影响版本"的人。
参考资源：
- CVE-2026-91403官方记录 ：www.cve.org/CVERecord?i...
- Oracle Critical Patch Update ：www.oracle.com/security-al...
- Spring Boot 4.0.6发布说明 ：spring.io/blog/2026/0...
- Spring Security CVE列表 ：spring.io/security