返回

2026/10/30

瀏覽器數小時內就獲得保護，企業 Java 呢？LOGIQ 如何因應 eMudhra 憑證事件

瀏覽器在數小時內封鎖了遭入侵的 eMudhra 中繼憑證，但每個 JDK 都有自己的信任儲存區。Azul 與 BellSoft 推出了哪些更新、LOGIQ 做了什麼，以及現在該檢查什麼。

重點摘要

  • 2026 年 10 月 17 日，Mozilla 接獲通報，指出 eMudhra 八張中繼 CA 憑證的私鑰已遭洩漏。各瀏覽器在數小時到數天內將其封鎖。eMudhra 表示，目前並未發現任何這些金鑰遭利用的證據。
  • Java 不採用瀏覽器或作業系統的信任判斷。每個 JDK，以及每個內含 JDK 的容器映像檔或應用程式，都帶有自己的信任儲存區，而且每一個都需要個別更新。
  • Azul 推出了兩次非例行的 Zulu 更新，分別在 10 月 21 日與 10 月 24 日。第二次更新是因為第一次的修正不夠完整，因此 10 月 21 日的因應措施單獨使用已不再足夠。
  • BellSoft 列出了 Java 8、11、17、21、25 與 27 的已修正 Liberica 組建。LOGIQ 已透過我們的 BellSoft 支援管道取得這些組建，並提供給客戶使用。
  • 該怎麼做：找出您執行的每一個 Java 執行環境，確認確切的供應商與組建版本，升級到該供應商的已修正組建，測試 TLS 連線，並持續留意非例行發布。

事件經過

2026 年 10 月 17 日（星期六）UTC 20:06，Mozilla 接獲通報，指出 eMudhra 八張中繼憑證的私鑰已遭洩漏。Mozilla 透過其集中式撤銷清單 OneCRL 在 Firefox 中封鎖了這八張憑證，該更新在 UTC 22:59 前就已送達使用標準設定的使用者，前後不到三小時。Mozilla 於 10 月 20 日公開揭露此事件。Mozilla 也為設定會阻擋 OneCRL 更新的使用者推出了 Firefox 小版本更新，並將簽發這些中繼憑證的根憑證從 NSS 信任儲存區中移除。

風險在於憑證偽造。持有其中任一把金鑰的人，可以為自己並未掌控的網站簽發 HTTPS 憑證。若對方還能介入用戶端與該網站之間，就能冒充該網站，讀取或竄改傳輸內容。

到目前為止，沒有證據顯示此事已經發生。eMudhra 在其事件聲明中表示，這八張中繼憑證已於 10 月 18 日撤銷，且均未簽發任何終端實體憑證，並表示「並未發現任何證據顯示在問題揭露之前，有人復原或利用了這些弱金鑰」。eMudhra 說明，起因是 2025 年金鑰儀式中產生的弱金鑰。該公司表示尚未確認確切的根本原因，調查仍在進行中。各瀏覽器的根憑證計畫已基於預防措施，對這些中繼憑證上層的 eMudhra 根憑證取消信任。

因此，本文的重點是關閉一段暴露風險的空窗期，而非一起已確認的攻擊。

為什麼 Java 需要另外修正

瀏覽器與作業系統都有自動停止信任某個憑證授權單位的機制，而且這次都很快就啟用了。根據 Azul 對此事件的說明，Chrome 在同一天封鎖了這些憑證，Apple 在 10 月 19 日，Microsoft 則在 10 月 20 日。

Java 不會沿用上述任何措施。JDK 是根據自己的檔案來決定信任哪些憑證：

  • 自己的信任儲存區。每個 JDK 都附帶自己的 cacerts 檔案。更新作業系統的憑證套件或重新啟動瀏覽器，都不會改變它。
  • 預設不檢查撤銷狀態。如 Azul 的文件所述，Java 信任這些中繼憑證所串連到的根憑證，而且「預設不會檢查撤銷狀態」。eMudhra 撤銷中繼憑證這件事本身，並無法保護 Java 用戶端。
  • 許多副本。一台伺服器可能同時執行系統 JDK、應用程式內附的 JDK、jlink 執行環境以及多個容器映像檔，各自擁有一份信任儲存區副本。每一份副本在更新或重新建置之前都仍然暴露在風險中。

因此，即使公司裡的每個瀏覽器都已受到保護，對外發起 TLS 連線的 Java 服務仍可能接受偽造的憑證。這正是本文要談的缺口。

Azul 的兩次緊急更新

Azul 在其 10 月季度發布之後，為 Azul Zulu 推出了兩次非例行更新：

  • 10 月 21 日：第一次非例行更新將八張遭入侵的中繼憑證加入 JDK 的封鎖清單（JDK 11 及以後版本為 blocked.certs，較舊版本為 blacklisted.certs），涵蓋 Zulu 27、25、21、17、11、8、7 與 6。Azul 的 CVE 清單將其記錄為 CVE-2026-91403。針對無法立即更新的執行環境，Azul 也發布了替換封鎖清單檔案的手動因應措施。
  • 10 月 24 日：Azul 發現封鎖清單並未完全解決問題。第二次非例行更新修正了 CVE-2026-114820（JSSE，基本分數 9.1），做法是將特定 CA 憑證從 cacerts 中完全移除。截至撰文時，這些組建提供給 Azul 僅含安全性修正的 CPU 系列，包括以 2026 年 10 月 CPU 為基礎的版本（例如 Zulu 21.53.114、17.69.114、11.91.114 與 8.97.0.112），以及以 2026 年 7 月 CPU 為基礎的版本。Azul 表示 PSU 組建「很可能」會在另一次更新中推出。

10 月 24 日的更新改變了建議內容。Azul 的因應措施頁面現在警告，該措施「已無法完全解決問題」，Azul 也要求所有客戶更新至最新版本。如果您已套用 10 月 21 日的更新或該因應措施，仍然需要 10 月 24 日的組建。Azul 在自己的說明文章中表示，從決定重新建置到客戶拿到僅含安全性修正的組建，大約花了 12 小時。

BellSoft 為 Liberica JDK 推出了什麼

BellSoft 於 10 月 21 日發布了例行的 2026 年 10 月 Liberica JDK 版本。該季度版本列出 52 個已修正的 CVE，並包含 Java 6 與 7 的 CPU 組建（6u521 與 7u521）。其版本說明並未涵蓋 eMudhra 問題。

BellSoft 在另一份指南「Distrusting compromised eMudhra intermediates in Java」（最後更新於 10 月 27 日）中說明 eMudhra 問題。指南列出的已修正組建為 Liberica JDK 8u513+9、11.0.33.0.3+7、17.0.21.0.3+5、21.0.13.0.3+5、25.0.5.0.3+5 與 27.0.1.0.3+5。對於暫時無法更新的系統，該指南提供了暫時的緩解措施：將受影響的根憑證從信任儲存區中移除。指南也警告，此做法可能會使合法的憑證鏈失效，應先進行測試。

比較各供應商時，有兩點值得注意：

  • CVE 清單並不相同。Azul 與 BellSoft 各自發布 10 月週期的 CVE 清單，數量與說明都有差異。上述兩個 Azul CVE ID 來自 Azul 的紀錄，BellSoft 的指南並未引用。請查閱您所用供應商的版本說明，確認您的組建包含哪些修正，不要假設某家供應商的清單適用於另一家供應商的 JDK。
  • Java 6 與 7 不在 BellSoft 的 eMudhra 清單中。BellSoft 已提供最新的 Java 6 與 7 組建，但其 eMudhra 指南中的已修正組建清單從 Java 8 開始。如果您執行的是 Liberica 6 或 7，請在依賴它之前先確認您的組建是否包含信任儲存區的變更，或者套用供應商提供的緩解措施。Azul 則列出了 Zulu 6 與 7 的 10 月 24 日組建。

LOGIQ 的因應方式

我們向客戶發行 BellSoft 與 Azul 的 Java 組建，並協助客戶從舊版 Oracle JDK 移轉。以下是我們採取的行動，以及截至撰文時（10 月 29 日）各項目的狀態。

已完成

  • 10 月 21–22 日：審閱供應商通知。我們收到並審閱了 Azul 10 月 21 日的非例行更新通知，以及 BellSoft 2026 年 10 月的版本通知，並在同一天為兩家供應商建立了下載與儲存庫作業。我們將兩次發布分開處理，並未假設 BellSoft 的季度版本包含與 Azul 相同的 eMudhra 修正。
  • 10 月 23 日：Liberica 季度組建上架準備。我們從 BellSoft 的支援入口網站下載了 2026 年 10 月的 Liberica JDK 組建，並加入客戶下載用的儲存庫。
  • 10 月 24–25 日：追蹤 Azul 第二次更新。我們掌握了 Azul 10 月 24 日的通知，包括即使已安裝 10 月 21 日組建也應更新的建議。
  • 10 月 27–28 日：透過 BellSoft 取得已修正的 Liberica 組建。我們透過商業支援關係，請 BellSoft 在我們的支援入口網站上提供最新組建。BellSoft 於 10 月 28 日上傳，包括 Java 8、11、17、21、25 與 27 的已修正組建，以及最新的 Java 6 與 7 組建。由於部分客戶仍需要 32 位元的 Java 8，我們也請 BellSoft 將 Windows 與 Linux 版的 32 位元 8u513+9 安裝程式加入我們的入口網站，BellSoft 當天就完成了新增。
  • 10 月 28–29 日：更新儲存庫與移轉對應。我們將這些組建加入客戶下載儲存庫，並更新 Oracle JDK 移轉至 Liberica 的指引，使其指向這些組建，此次更新並由第二位工程師審查。

Azul Zulu 客戶

Azul 10 月 21 日與 10 月 24 日的組建，Azul 訂閱客戶可透過 Azul 取得。適合的組建取決於您的 Java 版本、使用的是 CPU 還是 PSU 系列，以及您所在的基礎版本（10 月或 7 月）。請查閱 Azul 的版本說明以確認您的確切組建，或詢問我們，我們會協助您找出合適的版本。

舊版 Java 6 與 7

部分客戶仍在執行 Java 6 或 7，通常是用在無法快速移轉的應用程式中。Oracle 已不再為這些版本提供公開更新，但它們並非沒有選擇。我們協助客戶從舊版 Oracle JDK 6 與 7 組建移轉到最新的 Liberica JDK 6 與 7 組建，而 BellSoft 這兩個版本的 2026 年 10 月組建，我們都可以透過 BellSoft 的支援入口網站取得。當這些版本缺少我們需要的修正或套件時，我們會透過商業支援管道向 BellSoft 提出。就本次事件而言，請參閱上方說明：在依賴您的 Java 6 或 7 組建之前，先確認它包含 eMudhra 信任儲存區的變更。

您現在應該做什麼

1. 找出每一個 Java 執行環境

列出所有執行 Java 的地方，而不只是系統 JDK。這包括應用程式伺服器、供應商產品內附的執行環境、jlink 映像檔、CI 建置代理程式以及每一個容器映像檔。在 Linux 上，以下指令可找出主機上的 Java 執行檔：

find / -xdev -type f -path "*/bin/java" 2>/dev/null

對於容器映像檔，請在映像檔內執行檢查，例如 docker run --rm --entrypoint java <image> -version。

2. 確認確切的供應商與組建版本

只看主要版本號是不夠的。您需要供應商名稱與完整的組建編號，才能比對供應商的已修正組建清單：

java -XshowSettings:properties -version 2>&1 | grep -E "java.vendor =|java.runtime.version|java.home"

作為快速的參考指標，您也可以列出執行環境信任儲存區中的 eMudhra（emSign）根憑證：

keytool -list -keystore "<java.home>/lib/security/cacerts" -storepass changeit | grep -i emsign

在我們以 BellSoft 公開容器映像檔進行的測試中，較舊的 Liberica 21.0.10 組建列出了五張 emSign 根憑證，而已修正的 21.0.13.0.3+5 與 8u513 組建則一張也沒有。結果為空是好跡象，但並非證明。例如 Azul 10 月 21 日的修正封鎖了中繼憑證，但並未移除根憑證。組建編號才是可靠的檢查依據。我們先前關於檢查 Java 信任儲存區的文章介紹了更詳細的檢查方式。

3. 取得最新的適用修補程式

  • Azul Zulu：升級到您所用系列（CPU 或 PSU、10 月或 7 月基礎版本）的 10 月 24 日非例行組建，即使您已安裝 10 月 21 日的組建或已套用因應措施也一樣。如果您使用 PSU 組建，請留意 Azul 後續的 PSU 發布。
  • Liberica JDK：升級到 BellSoft 列出的已修正組建（8u513+9、11.0.33.0.3+7、17.0.21.0.3+5、21.0.13.0.3+5、25.0.5.0.3+5、27.0.1.0.3+5）。
  • 其他供應商與內附執行環境：請查閱該供應商的安全性公告。第三方產品內的 JDK 由該產品的供應商負責更新，而不是透過您的作業系統更新。
  • 容器：以已修正的基礎映像檔重新建置映像檔並重新部署。修補執行中的容器並不會改變映像檔。

4. 在部署前與部署期間驗證 TLS

從信任儲存區移除根憑證可能會導致合法連線中斷，例如連往仍使用串連至已移除 eMudhra 根憑證之憑證的網站。eMudhra 表示，正從另一套 CA 階層重新簽發受影響客戶的憑證。在大規模部署之前，請先測試應用程式所依賴的對外 TLS 連線，特別是連往可能使用 eMudhra 憑證的合作夥伴或服務。請分階段部署，重新啟動 Java 處理程序以載入新的信任儲存區，並在完成後確認執行中的版本。

5. 留意非例行發布

這起事件在四天內催生了兩次緊急 Java 發布，之後可能還會有更多，例如 Azul 的 PSU 組建。請訂閱各供應商的安全性通知，直接查看其發布頁面，而不要只依賴電子郵件，並為季度排程以外的 Java 更新預作規劃。

啟示

Firefox 使用者能在數小時內獲得保護，是因為瀏覽器有自己的信任儲存區，以及自動更新的機制。企業 Java 則有許多信任儲存區、預設不檢查撤銷狀態，而且更新要等有人去安裝。要補上這個缺口，需要準確的資產清冊、確切的組建編號、快速取得供應商組建的管道，以及不必等待下一次季度修補的處理流程。如果您需要協助找出或更新環境中的 Java 執行環境，歡迎聯絡 LOGIQ。

參考資料