Oracle 罕見於季更新隔天發布緊急安全警示！Java 爆 CVSS 9.1 漏洞，急封 eMudhra 弱金鑰憑證

Oracle 在 2026 年 10 月 21 日發布獨立於每季更新之外的緊急安全警示 (Security Alert) CVE-2026-91403。此漏洞影響 Oracle Java SE、Oracle GraalVM for JDK 與 Oracle GraalVM Enterprise Edition，CVSS v3.1 基本分數為 9.1。值得注意的是，Oracle 前一天才剛發布 10 月的 Critical Patch Update，隔天又單獨為 CVE-2026-91403 發出警示，這是 Java 與 Oracle 對 eMudhra 弱金鑰事件的回應。

漏洞概要

CyberQ 觀察，根據 Oracle 官方公告，這項漏洞位於 JSSE 元件，可透過多種通訊協定遠端利用，且不需驗證身分，攻擊者不必持有帳號密碼即可透過網路發動攻擊。CVSS 向量為 CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N，也就是攻擊複雜度低、不需使用者互動，成功利用後對機密性與完整性都有高度影響，但不影響可用性。

受影響的版本如下

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 Edition 21.3.20

請特別留意，上述版本正是 10 月 20 日 CPU 剛釋出的最新版本，換言之，前一天才更新完的環境仍在受影響範圍內。Oracle 也在公告中說明，未在 Premier Support 或 Extended Support 範圍內的舊版本並未經過測試，但很可能同樣受影響，建議升級至受支援版本。

Oracle 另在附註中指出，此漏洞可透過該元件的 API 被利用，例如由 Web 服務向這些 API 提供資料的情境，同時也適用於執行沙箱 Java Web Start 應用程式或 Java applet 並仰賴 Java 沙箱保護的用戶端。

根本原因，eMudhra 中繼憑證私鑰可被任何人算出

Oracle 的公告並未說明技術細節，官方通報並未描述根本原因。但從 OpenJDK 同日發布的通報與多家外媒報導可以確認，這次事件與印度憑證機構 eMudhra 的金鑰外洩事件直接相關。Oracle 週三發布的這份獨立安全警示，目的是讓 Java SE 與 GraalVM 執行環境不再信任八張已遭破解的 eMudhra 中繼 CA 憑證。

事件起點在 10 月 17 日。一位名為 Wayne 的安全研究人員在比對 Common CA Database (CCADB) 時發現，eMudhra 簽發的八張中繼憑證所使用的私鑰極為脆弱，任何人都能在一秒內從公開憑證反推出私鑰。依 Mozilla 的事件報告，這八把金鑰來自 eMudhra 在 2025 年 4 月 30 日產生的一批 24 張中繼憑證。安全研究人員 Scott Helme 分析後發現，其中一把私鑰的數值就是 4，其他研究人員則找到 66、155、156、230 與 237 等數值。

以橢圓曲線密碼學的標準而言，私鑰應是一個超過一百位數的隨機整數。當私鑰小到可以用暴力法逐一試出，持有該私鑰的任何人都能以該中繼 CA 的名義為任意網域簽發憑證。Cloudflare 在其公告中指出，由於金鑰本身脆弱，攻擊者可以為任何網域偽造憑證，用以冒充伺服器並攔截或竄改流量，這是一起影響範圍遍及整個網際網路的重大安全事件。

eMudhra 方面的說法是，2025 年 4 月的金鑰產生儀式存在瑕疵，在預期的金鑰之外額外產生了一組脆弱金鑰，而發布到瀏覽器根憑證庫的正是那組脆弱金鑰。

為什麼 Java 需要單獨修補

CyberQ 觀察，雖然瀏覽器已在幾天內透過各自的撤銷機制封鎖這些憑證，但 Java 卻必須另行發布修補，原因在於 Java 自己維護一份根憑證清單。從 Oracle、Adoptium 等廠商單獨安裝的 Java，是依據內建的 lib/security/cacerts 檔案決定信任哪些根憑證，不會使用作業系統或瀏覽器的清單。

更關鍵的是防禦機制的差異。瀏覽器能拒絕這些中繼憑證，是因為 Mozilla、Chrome、Apple 與 Microsoft 各自透過自家機制推出撤銷資料，而且瀏覽器還要求憑證透明度 (CT)，會拒絕未出現在公開日誌中的憑證。Java 標準 TLS 實作預設不會抓取撤銷資料，也不要求 CT。

這八張憑證還有一個容易被忽略的面向。八張遭破解的中繼憑證中，六張用於 TLS，兩張用於程式碼簽章，而它們鏈結到兩個根憑證，一個是 eMudhra 的 emSign ECC Root CA – G3，另一個是 Sectigo 的 AAA Certificate Services。Sectigo 曾對相同的公鑰做交叉簽署，由於金鑰相同，這條路徑同樣已遭破解。這意味著即使從信任庫移除 eMudhra 的根憑證，若 Sectigo 的交叉簽署憑證未被封鎖，信任鏈仍可成立。

在預設設定下，實測 OpenJDK 27.0.1 成功連線至兩個測試主機，均回傳 HTTP 200，也就是說，一台未修補的 Java 應用程式伺服器在對外呼叫 HTTPS 服務時，會接受由這些遭破解憑證簽發的偽造憑證。

OpenJDK 的修補內容與修正版本

OpenJDK 本身的修正 (8395142: CA Enhancements) 將相同的 16 張憑證加入 blocked.certs.pem，並調整該檔案的產生方式，使 ECDSA 簽章的替代編碼也能被比對。16 張憑證指的是八張原始中繼憑證加上八張 Sectigo 交叉簽署憑證。

修正版本號方面，OpenJDK 通報並未列出修正版本，研究人員的測試網站則列出修正後的 Java 版本為 27.0.1.0.2、25.0.5.0.2、21.0.13.0.2、17.0.21.0.2、11.0.33.0.2 與 8u511，建議讀者以 Oracle 公布的修補可用性文件為準。

企業應採取的措施

CyberQ 建議第一優先仍是更新 Java。Oracle 客戶應安裝安全警示中所連結的 Java SE 修補可用性文件所列的修補版本。若無法立即更新，OpenJDK 通報提供兩項暫時措施。

替換 blocked.certs 檔案

通報指示下載對應作業系統的新版 blocked.certs，替換 $JDK_HOME/lib/security/blocked.certs，JDK 8 的檔名則是 blacklisted.certs，替換前應先備份並保留自行加入的項目。

開啟撤銷檢查

Java 的 TLS 堆疊預設不做撤銷檢查，可透過兩個系統屬性開啟

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

實測中 OpenJDK 27.0.1 與 Temurin 25.0.4.1 在開啟後都以 CertificateRevokedException 拒絕了遭破解的中繼憑證，理由為 CA_COMPROMISE。不過此作法有代價，撤銷檢查會在每次連線時抓取 CRL，若發布點無法連線，連線就會失敗。

安裝方式不同，處理方式也不同。Arch Linux、Debian、Fedora、Gentoo、Oracle Linux、RHEL、Ubuntu 等發行版的 OpenJDK 套件多半使用作業系統憑證，更新 OS 的 ca-certificates 即可。Homebrew 與 FreeBSD 的 OpenJDK 套件則內建憑證，需更新 Java 套件本身。

程式碼簽章也要一併檢視。八張中繼憑證中有兩張用於程式碼簽章，涉及已簽章 JAR 的驗證，通報指出 JDK 17 以上可使用 jarsigner -verify -revcheck -strict 一併檢查撤銷狀態。

幾點提醒

CyberQ 指出，關於 CVSS 9.1 這個分數，Oracle 說明其 Java CVSS 評分假設 applet 等程式碼以系統管理員權限執行，若非如此，分數會較低。企業應依自身的 Java 使用情境評估實際風險，但這不代表可以延後修補，伺服器端出站 TLS 連線同樣受影響。

關於是否已有實際攻擊，目前沒有確認證據顯示 CVE-2026-91403 已遭野外利用，Oracle 亦未將此次 CPU 中的任何漏洞標記為已遭利用。另外，依研究人員測試網站的說法，封鎖前 CT 日誌中並未出現鏈結到這些中繼憑證的任何憑證。這些都是正面訊號，但脆弱金鑰從 2025 年 4 月 30 日產生到 2026 年 10 月 17 日瀏覽器開始封鎖，曝險期間長達約 17 個月，期間是否曾有未被記錄的濫用，目前無法排除。

CyberQ 提醒維運團隊，要留意 Oracle 公告的修補節奏，安全修補於每月第三個星期二發布，無 CPU 的月份則發布 Critical Security Patch Update (CSPU)，下一次是 2026 年 11 月 17 日的 CSPU。

CyberQ 指出，對於需要符合 ITGC 或 ISO 27001 要求的組織，這次事件也適合作為檢視內部憑證信任庫管理流程的契機，包括 Java 內建 cacerts 是否納入資產清單、撤銷檢查政策是否有明文規範，以及程式碼簽章驗證流程是否涵蓋中繼憑證撤銷狀態。