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 版本——先查清楚你到底跑的是誰的構建。這一步不做，後面全是無用功。
四、那到底該做什麼
- 先確認版本。跑
java -version，比對上面對照表。8u511 / 11.0.33 / 17.0.21 / 21.0.13 / 25.0.5 / 27.0.1 這些是受影響版本，不是修復版本。 - 別隻訂閱 CPU。把 Security Alert 和 CSPU 一起納入監控，用 CVE-to-Advisory 映射表做入口，別依賴單一頁面。
- 拆開向量再做排序。至少把 A（可用性）這一項單獨拉出來看，別讓「9.1 分」這三個字代替判斷。
- 查清 vendor。你打的是哪個供應商的補丁、那個供應商合了沒有，這纔是修復的真正路徑。
- 別指望緩解措施。這條公告裏 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。想看逐項風險矩陣的文本版，公告頁裏有鏈接。