本博客日IP超过2000，PV 3000 左右，急需赞助商。
极客时间所有课程通过我的二维码购买后返现24元微信红包，请加博主新的微信号：xttblog2，之前的微信号好友位已满，备注：返现
受密码保护的文章请关注“业余草”公众号，回复关键字“0”获得密码
所有面试题(java、前端、数据库、springboot等)一网打尽，请关注文末小程序
【腾讯云】1核2G5M轻量应用服务器50元首年，高性价比，助您轻松上云
今年以来，漏洞悬赏、黑客马拉松之类的活动占比逐渐在下降，而 AI 发现的漏洞却一直在增多。这导致 Spring 以及 Java 等生态在内的众多框架或中间件都受到了影响。
我在前面文章也已提到，Spring 今年竟然成了新的“漏洞之王”，还有不少开源项目迫不得已把 issues 给关闭了，只开放 PR。原因就是很多 issues 是 AI 提的，社区维护人员已经看不过来了，所以不少社区提倡有问题直接提 PR，别 BB。
最近在漏洞方面的大新闻当属 php2shell 了，涉及全球 70 以上的网站安全。随后各大语言也都爆出了各类漏洞，包括：nodejs、rust、go、java 等等。这其中，Java 25.0.5 刚发布，第二天就被 9.1 分漏洞“追着打”，迫使 Java 直接来了一个小版本 3 连发。
Java 小版本 3 连发
10 月 20 日，Oracle 发布 Java SE 25.0.5，版本号为 25.0.5+9，属于 2026 年 10 月 Critical Patch Update 周期更新。随之一同抬升的安全基线包括：Java 25 → 25.0.5+9，Java 21 → 21.0.13+10，Java 17 → 17.0.21+9，Java 11 → 11.0.33+9，Java 8 → 1.8.0_511-b09。
但戏剧性的是，10 月 21 日，Oracle 又针对 CVE-2026-91403 发布紧急安全公告，CVSS 3.1 评分 9.1，受影响组件是 JSSE，连“前一天刚发的 25.0.5”也在影响列表里。也就是说，只装上 10 月 20 日的季度更新，并不等于万事大吉。
就拿 JDK 25 来说，25.0.5 -> 25.0.5.0.2；2 个小版本连续发布，这在 Java 史上仅此一例。但这还没完，前天又紧急发布了 25.0.5.0.3。
有人可能会说 25.0.5.0.1 哪去了？我看了官方文档，说原本是有 25.0.5.0.1 的，但由于到了 CPU（关键补丁更新） 发布周期就一起合并到 JDK 25.0.5 之中了。
Java 一次发布这么多的版本更新，表明在安全更新这方面比 PHP 就好很多，PHP 的很多老旧版本早就不维护了，很多老系统出于裸奔状态。
Java 25.0.5 更新了什么？
Java 25.0.5 虽然是关键补丁更新，但这个小版本是汇聚了一个季度累积的安全补丁集合，从更新的内容来看相当丰富了。
拥抱后量子混合密钥交换
这是 25.0.5 里最值得开发者关注的能力之一。JDK 为 TLS 1.3 实现了后量子混合密钥交换，支持三组算法。
X25519MLKEM768SecP256r1MLKEM768SecP384r1MLKEM1024
其中 X25519MLKEM768 默认启用且优先级最高。它的思路很直接，把传统椭圆曲线 X25519 与抗量子 ML-KEM 做“混合”，即使未来量子计算对 ECDH 构成威胁，握手仍保留一道基于格的防线。对普通服务来说，只要对端也支持 X25519MLKEM768，就无需改 API、无需改配置。下面参数排查时可用：
-Djavax.net.debug=ssl:handshake观察 ServerHello 的 key_share 扩展里是否出现 x25519mlkem768。
证书信任策略继续收紧
25.0.5 调整了 jdk.security.caDistrustPolicies，所有由 Symantec、Entrust、Camerfirma 根 CA 锚定的 TLS 服务端证书，不论签发日期，都将被不信任；由 Chunghwa 根 CA 锚定的证书则从 2027 年 4 月 19 日 起完全不被信任。同时，cacerts 移除了 LuxTrust Global Root CA。
这类变更对老系统很“疼”，应用可能没改一行代码，但升级到 25.0.5 后，旧证书链突然握手失败。一批老 CA 被默认不信任，典型报错会集中在 PKIX path validation、certificate unknown、unable to find valid certification path 附近。
内置 HttpServer 校验 Host 头
com.sun.net.httpserver.HttpServer 按 RFC 9112 校验 Host 请求头。HTTP/1.1 请求缺少 Host，或出现多个 Host，将返回 400 Bad Request。确有必要时可用系统属性临时关闭：
-Dsun.net.httpserver.disableHostValidation=true但这属于安全回退开关，不建议在公网服务上长期打开。
RMI URL Reference 更保守了
JNDI/LDAP 的 RMI URL Reference 默认更保守了。JDK 扩展了 com.sun.jndi.ldap.object.trustSerialData 的作用范围：当禁用来自 LDAP 的反序列化时，内置 JNDI/LDAP Provider 不再透明处理 LDAP Reference 中 scheme 为 rmi 的 URL Reference，而是直接返回 Reference 对象。新增系统属性：
-Djdk.jndi.ldap.disabledURLSchemes=rmi,ldap,http用于更细粒度地禁用某些 URL scheme。依赖“LDAP 引用自动转 RMI 查找”的老应用，升级后可能需要显式处理 Reference，或调整该属性。
禁用 TemplatesImpl 反序列化
JAXP 默认禁用 TemplatesImpl 反序列化。com.sun.org.apache.xalan.internal.xsltc.trax.TemplatesImpl 是 XSLT 相关内部类，历史上多次成为反序列化利用链的关键一环。25.0.5 起默认禁止反序列化该类型，触发时将抛出 UnsupportedOperationException。如确有兼容需要，可用以下属性恢复，但务必评估风险。
-Djdk.xml.enableTemplatesImplDeserialization=truePKCS12 KeyStore 增强
PKCS12 KeyStore 支持更现代的 PBMAC1，JDK 的 PKCS12 KeyStore 支持 RFC 9879 的 PBMAC1 完整性保护算法。可在 java.security 中设置。
keystore.pkcs12.macAlgorithm=PBEWithHmacSHA256已有 keystore 文件仍沿用创建时的完整性算法；新文件会使用 PBMAC1。Oracle 也提示，未来版本会把 PBMAC1 设为默认。
WebRowSet 解析报错更统一
WebRowSet.readXml 对畸形 XML、Schema 校验失败、不支持的外部实体等处理，统一改为抛出 SQLException。可用：
-Djdk.sql.rowset.webrowsetValidation=false关闭校验。方法签名未变，但异常语义更严格了。
组件与第三方库修复
25.0.5 的修复清单还包含一批稳定性和性能问题，例如：HarfBuzz 升级到 14.2.0，FreeType 升级到 2.14.3，GIFlib 升级到 6.1.3，Libpng 升级到 1.6.58；修复 AOTCache 峰值吞吐下降、特定 CPU 指令集下 AOT cache 启动 SIGILL、x86 double_keccak stub 未正确设置返回值、G1 “可选疏散”错误搬运 pinned object、native heap trimmer 锁顺序可能导致死锁、ML-KEM 在 aarch64/PKCS11/JSSE 混合密钥交换中的若干实现问题等。
另外，25.0.5 主体随附 IANA tzdata 2026c；随后 25.0.5.0.1 BPR 又继续更新到时区数据 2026d/2026e，并同步微软对 British Columbia、Alberta、Manitoba 时区命名，现在 25.0.5.0.1 也已经合并到 25.0.5 版本中了。另外，涉及时区、排班、金融清算、日志时间解析的系统，升级后要专门回归 java.time 与 CLDR 相关用例。
CVE-2026-91403
如果说 25.0.5 是“常规季度安全更新”，那 #CVE-2026-91403 就是典型的“证书信任链黑天鹅”。
公开风险评估显示：该漏洞位于 JSSE，攻击向量是网络，攻击复杂度低，无需权限、无需用户交互；成功利用可能导致对关键数据的未授权创建、删除、修改或访问。受影响版本包括 Oracle Java SE 的 8u511、8u511-perf、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 21.3.20。
根因并非“P-384 被破解”，而是 CA eMudhra 在密钥生成环节出了严重事故：8 组中间 CA 私钥本应来自 P-384 椭圆曲线，实际私钥值却小到离谱，参考我上篇文章中提到的其中三组分别是 4、56、115 等。安全研究人员 Scott Helme 用普通笔记本不到一秒就恢复了全部 8 组私钥。问题从 2025 年 4 月 30 日存在到曝光，约 18 个月，期间还经过两轮独立审计。
这个漏洞对 Java 的威胁在于，一些应用并不做有效证书吊销检查。即使 CA 已经撤销问题证书，只要客户端信任链仍能接纳由这些弱私钥伪造出的证书，攻击者在能拦截或重定向流量的场景里，就可能冒充站点、读写敏感数据。需要说清楚的是，这更接近“信任伪造身份导致机密性/完整性受损”，不等于所有 Java 服务器被一键远程控制。
对应的连锁反应很快，Google、Mozilla 在 10 月 17 日通过浏览器证书封锁机制防护；eMudhra 撤销 8 张中间 CA 证书，Sectigo 撤销相关交叉签名；Mozilla 通过 NSS 移除关联根证书，Chrome 也计划从根证书库移除 emSign ECC Root CA - G3。初步估计约 3 万张合法证书需要迁移，主要因为根证书信任关系变化，而不是这些证书本身私钥弱。事件后三个交易日，eMudhra 股价累计下跌约 38%，公司随后宣布自愿退出全球 SSL/TLS 证书业务。
影响版本
这事最容易踩坑，不要只看大版本号。
| 系列 | 10 月 20 日 CPU 更新 | 10 月 21 日 alert 后状态 | 修复/处置要点 |
|---|---|---|---|
| Java 27 | 27.0.1 | 27.0.1 仍受影响 | 看 27.0.1.0.2 及之后构建 |
| Java 25 LTS | 25.0.5 | 25.0.5 仍受影响 | 确认 ≥ 25.0.5.0.2 / 10 月 21 日后构建 |
| Java 21 LTS | 21.0.13 | 21.0.13 仍受影响 | 确认 ≥ 21.0.13.0.2 |
| Java 17 LTS | 17.0.21 | 17.0.21 仍受影响 | 确认 ≥ 17.0.21.0.2 |
| Java 11 LTS | 11.0.33 | 11.0.33 仍受影响 | 确认 ≥ 11.0.33.0.2 |
| Java 8 | 8u511 | Oracle 重发 8u511 | 按下载日期/构建核对，拿不准就重下 |
建议，大家从 Oracle 公开下载页随后提供过 JDK 11.0.33.0.2、17.0.21.0.2、21.0.13.0.2 等更新构建；Java 8 的 8u511 因版本号没变，更要用下载时间、文件哈希或发行版公告确认。
如果你用的不是 Oracle JDK，而是 Temurin、Corretto、Zulu、OpenJDK 发行包或 Linux 发行版自带 JDK，不要硬套 Oracle 版本号；要核对对应供应商的安全构建与公告。OpenJDK 侧受影响的表述也是“25.0.5 及更早/相关旧版本同样可能受影响”。
结语
Java 25.0.5 本身是一次内容很实的更新。后量子 TLS、证书信任收紧、JNDI/JAXP 默认安全化、PKCS12 PBMAC1，再加上一批性能和稳定性修复。但 10 月 21 日的 CVE-2026-91403 漏洞提醒我们，Java 也会遭遇“黑天鹅”。现代 Java 安全不只取决于 JDK 代码漏洞，也取决于 JDK 自带信任根、CA 运营、证书吊销策略和发行版供应链的共同状态。
这个 10 月的软件行业并不太平，各类语言或多或少的都遭遇到了安全漏洞问题。只不过有些漏洞本是可以避免的，只是印度程序员太不靠谱了，再次证明了世界是一个巨大的草台班子！
最后，我再剧透一下，Java 25.0.5.0.3 在上周六也紧急发布了。
最后，欢迎关注我的个人微信公众号：业余草（yyucao）！可加作者微信号：xttblog2。备注：“1”，添加博主微信拉你进微信群。备注错误不会同意好友申请。再次感谢您的关注！后续有精彩内容会第一时间发给您！原创文章投稿请发送至532009913@qq.com邮箱。商务合作也可添加作者微信进行联系！
本文原文出处：业余草： » Java 遭遇 JSSE 黑天鹅，JDK 25.0.5 已过时 2 个版本了