Java 出了个 9.1 分漏洞 CVE-2026-91403，可我照着 Oracle 公告查了一圈，发现两个大坑

先说结论：CVE-2026-91403 是真的，CVSS 3.1 打 9.1，也确实严重。但它不在这一季的 CPU 公告里，而且那个 9.1 分里没有「能用它执行代码」这一项。这两条如果没搞清，你打补丁的节奏和排序都会错。

这个洞是 Oracle 在 2026 年 10 月 21 日通过 Security Alert 单点发的，不是季度 Critical Patch Update 里的一条。组件是 JSSE，影响 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 EE 21.3.20。

我按标题的提示，老老实实去把 Oracle 的公告体系捋了一遍，结果发现两个坑比漏洞本身更值得写——因为这两个坑不是这一条漏洞的问题，是所有按「季度扫一次厂商公告」流程干活的团队都会踩的。

一、坑一：它不在这季度的 CPU 里

这条最反直觉。很多人（包括一个月前的我）对 Oracle 的安全节奏有个默认认知：每季度一次 CPU，十月有一次大的，扫一遍 1295 个补丁就完事了。

但 Oracle 的对外公告其实是三个池子：

• Critical Patch Update（CPU）——季度批量，攒一批一起发。
• Security Alert——紧急单点，不并入季度节奏，一个 CVE 可能单独开一页。
• Critical Security Patch Update（CSPU）——介于两者之间的补丁更新。

CVE-2026-91403 走的是第二个池子。我翻了这季度 CPU 那份公告的全文——1295 个新补丁、其中 Java SE 占 55 个、49 个可远程未授权利用——全文检索 CVE-2026-91403，命中 0 次。

这意味着什么？如果你的资产流程是「每季度抓一次 CPU 的 CVE 列表，导进漏洞库，排期修复」，那这条漏洞永远不会出现在你的清单里。不是被漏掉，是那条管道压根不覆盖这个数据源。

而 Oracle 在 Security Alert 里还专门加了一段话，大意是：Security Alert 发的补丁只覆盖处于 Premier Support 或 Extended Support 阶段的版本，不在支持周期里的版本不会被测试。翻译一下就是——老版本别来找我，升级。

顺带说，两个版本表还对不上

这个坑是查的时候顺手发现的，更值得警惕。

同一份十月节奏里，Java SE 出现了两套完全不同的版本号：CPU 那份列的是 8u503、11.0.32.1、17.0.20.1、21.0.12.1、25.0.4.1、26.0.2、27；Security Alert 这份列的是 8u511、11.0.33、17.0.21、21.0.13、25.0.5、27.0.1。

不是笔误，是两批不同的更新。以为「我打完这季度 CPU 就齐了」的，实际打的不是同一批版本。这种情况下最危险的不是没打补丁，是打了补丁之后以为自己安全了。

二、坑二：9.1 分，但不是 RCE

这条更微妙，也更容易被标题带偏。

CVE-2026-91403 的向量是 CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N，拆开看：

维度	取值	含义
AV 攻击向量	N（网络）	远程可达
AC 攻击复杂度	L（低）	不需要凑一堆前置条件
PR 所需权限	N（无）	未认证就能发起
UI 用户交互	N（无）	不用骗谁点链接
S 作用范围	U（不变）	影响局限在自身安全域
C 机密性	H（高）	关键数据可被读取
I 完整性	H（高）	关键数据可被创建/删除/修改
A 可用性	N（无）	Oracle 未标注服务中断影响

最后一行是关键。可用性是 None。

Oracle 的原文描述是：未授权的创建、删除或修改访问权限，加上未授权访问关键数据。全文没有出现 remote code execution 这个词。

这不是抠字眼。9.1 分是 C:H + I:H 撑起来的——能读、能改，破坏力确实大。但「能读能改」和「能执行任意代码」在处置上是两件事：前者往往意味着数据面被穿透，后者意味着整台机器易主。你按分数排序会把它们排在一起，按语义排就不会。

还有个细节别忽略：Oracle 说这个洞也可能影响那些加载并运行不可信代码的 Java 部署——典型场景就是跑在沙箱里的 Java Web Start 应用和 applet，靠 Java 沙箱兜底的那种。这个场景现在很少见了，但如果你的老系统里还有，那它是另一回事，因为沙箱一旦被穿，性质就变了。

另外补一句评测口径的坑：Oracle 明确说过，它的 CVSS 分数假设跑 applet 或 Web Start 的用户有管理员权限（Windows 上常见）。用户不是管理员时（Solaris、Linux 上常见），机密性、完整性、可用性三项的影响分数会从 High 降成 Low，基准分跟着掉一大截。同一个 CVE，在不同平台上分数可以完全不同。

三、一个漏洞要分三层看

这两个坑其实指向同一个方法论问题：大家都在抄分数做排序，却没人拆分数的语义和来源。

第一层：公告体系——它在哪个池子里发

这决定了你的自动化管道能不能捞到它。CPU、Security Alert、CSPU 是三条不同的通道，发布节奏、覆盖范围、甚至 URL 结构都不一样。只管 CPU 的流程，天然漏掉所有紧急单点。

实操上，最省事的做法是把厂商的CVE 到公告的映射表当成唯一入口，而不是抓某一份具体公告。Oracle 自己提供 Map of CVE to Advisory/Alert，这条链接比任何一份 CPU 页面都可靠。

第二层：评分语义——9.1 说的是哪几项

CVSS 是个可分解的量，不是个排名。C:H/I:H/A:N 的 9.1 和 C:H/I:H/A:H 的 9.1，处置优先级应该不一样——前者是「数据被偷改」，后者是「服务被打挂」外加前两条。

更实际的一点：看向量比看分数有用。AC:L + PR:N + UI:N 这三个凑一起，意味着攻击面是完全敞开的，不需要任何前置条件。这种洞就算分数只有 7 分，实际被利用的概率也远高于那些 9 分但要人点链接的。

第三层：供应链——到底是谁的构建

Oracle JDK 只是其中一家。你线上跑的可能是 OpenJDK 的某个发行版构建、可能是某个云厂商的定制 JDK、也可能是打包进容器镜像的第三方构建。CVE 修没修，取决于那个 vendor 有没有把上游补丁合进去，跟 Oracle 发没发补丁是两件事。

所以别看到 Oracle 发了公告就去查自己的 Oracle JDK 版本——先查清楚你到底跑的是谁的构建。这一步不做，后面全是无用功。

四、那到底该做什么

1. 先确认版本。跑 java -version，比对上面对照表。8u511 / 11.0.33 / 17.0.21 / 21.0.13 / 25.0.5 / 27.0.1 这些是受影响版本，不是修复版本。
2. 别只订阅 CPU。把 Security Alert 和 CSPU 一起纳入监控，用 CVE-to-Advisory 映射表做入口，别依赖单一页面。
3. 拆开向量再做排序。至少把 A（可用性）这一项单独拉出来看，别让「9.1 分」这三个字代替判断。
4. 查清 vendor。你打的是哪个供应商的补丁、那个供应商合了没有，这才是修复的真正路径。
5. 别指望缓解措施。这条公告里 Oracle 没给 workaround，信用声明写的是 None credited——既没说是谁报的，也没给绕行方案。这种情况只有打补丁一条路。

还有一条给做资产管理的：把「公告类型」当成一个字段存下来。CPU 发的和 Security Alert 发的，在响应 SLA 上本来就该不一样——前者可以走季度窗口，后者按紧急流程走。混在一张表里，紧急的会被季度的节奏拖死。

五、最后说句实在的

这条漏洞本身，9.1 分、未授权、网络可达、无交互、能读能改——该修，而且优先级不低。

但它带给我的收获不在漏洞本身，而在于它是怎么从我的视野里溜走的：一个不在季度公告里的紧急补丁、一套对不上的版本号、一个不含 RCE 的 9.1 分。三件事任意一件单独发生都不致命，凑在一起就变成了「以为处理完了，其实压根没看到」。

漏洞不可怕，可怕的是你的流程里根本没有它的位置。

顺便把数据都记一下，方便你自查：这季度 CPU 共 1295 个新补丁，Java SE 占 55 个，其中 49 个可远程未授权利用；CVE-2026-91403 走 Security Alert，2026 年 10 月 21 日 Rev 1 首发，只覆盖 Java SE 一个产品线。

链接放这儿：Oracle Security Alert – CVE-2026-91403。想看逐项风险矩阵的文本版，公告页里有链接。