CVE-2026-91403 是 2026 年 10 月 21 日公布的 Java 漏洞，嚴重度 9.1 分。它的真正原因是一家憑證機構 eMudhra 有 8 張「中繼憑證」的私鑰產生方式有缺陷，任何人都能算出來，拿到之後就能偽造任何網站的憑證、冒充那個網站。Java 自帶一份「信任名單」，裡面包含這些憑證，所以 Java 程式要更新，才不會被假網站騙過。
網路上不少報導把它寫成「駭客能直接對你的伺服器發動攻擊」，這個說法容易讓人誤解。比較準確的理解是：你的 Java 程式在連線到外部服務時，可能被冒充的假網站騙走或竄改資料。這篇用白話把來龍去脈講清楚，也整理企業該怎麼判斷自己有沒有受影響。
⚠️有在用 Java 的系統？先做這件事
請負責的工程師確認：系統用的 Java 版本，以及它用的是「Java 自帶的信任名單」還是「作業系統的信任名單」。用作業系統套件安裝的 Java，更新作業系統的憑證通常就夠；獨立安裝的 Java 要更新到 10 月 21 日之後的版本。細節見下方「該怎麼處理」。
CVE-2026-91403 懶人包：發生什麼事、影響誰
一句話：憑證機構的私鑰外洩，瀏覽器幾天內就封鎖了，但 Java、部分程式語言和作業系統工具有自己的信任名單，要另外更新。下面整理自 OpenJDK 官方公告、事件說明頁 與 Cloudflare 的說明。
項目 | 內容 |
|---|---|
漏洞編號 | CVE-2026-91403，嚴重度 9.1 分 |
根本原因 | 憑證機構 eMudhra 的 8 張中繼憑證，私鑰產生方式有缺陷，任何人都能從憑證算出私鑰 |
攻擊者能做什麼 | 偽造任何網站的憑證，冒充那個網站，攔截或竄改連線內容 |
受影響的 Java 版本 | 27.0.1、25.0.5、21.0.13、17.0.21、11.0.33、8u512 以及更早的版本（OpenJDK 公告） |
瀏覽器 | Firefox、Chrome 在 10 月 17 日、Apple 在 19 日、Microsoft 在 20 日就已經封鎖這些憑證 |
有沒有被利用 | Cloudflare 表示在自家服務上沒有發現實際利用；事件說明頁表示無法確定是否有人利用過 |
日期 | 發生什麼事 |
|---|---|
2025 年 4 月 | 這些中繼憑證建立，缺陷從這時候起就存在 |
2026 年 10 月 17 日 | 發現者用這 8 張憑證的私鑰簽了一段訊息，證明私鑰可以被算出，回報給各大瀏覽器與作業系統 |
10 月 17 日到 20 日 | Firefox、Chrome、Apple、Microsoft 陸續封鎖這些憑證 |
10 月 20 日 | 事件公開 |
10 月 21 日 | Java 發布更新並給予漏洞編號 CVE-2026-91403 |
先搞懂憑證：網站怎麼證明「我就是我」
網站的 SSL 憑證就像一張身分證，證明「這個網站真的是它說的那個網站」，並讓連線內容加密。這張身分證是由「憑證機構」發的，你的瀏覽器或程式之所以相信它，是因為裡面內建了一份「可信任的憑證機構名單」。完整的入門可以看 SSL 憑證是什麼。
用印章比喻最好懂：憑證機構像是戶政事務所，中繼憑證像是事務所授權給各分處的印章。只要蓋了這個印章，大家就相信這份文件是真的。這次的問題是，有 8 個分處的印章是用很容易仿造的方式刻的，任何人都能照著刻一個一模一樣的。有了這個印章，就能幫任何網站「開身分證」，包括銀行、金流、你公司在用的 API。
角色 | 生活比喻 | 這次發生什麼事 |
|---|---|---|
根憑證 | 戶政事務所總部 | 沒有直接出問題 |
中繼憑證 | 總部授權給分處的印章 | 8 個印章可以被任何人仿造 |
網站憑證 | 分處發給民眾的身分證 | 攻擊者能拿仿造的印章，替任何網站開假身分證 |
信任名單 | 大家認可的事務所與印章清單 | 要把這 8 個印章從清單上拿掉，各家更新的速度不同 |
為什麼瀏覽器沒事，Java 卻要更新
一句話：瀏覽器有自己的快速封鎖機制，Java 用的是自己內建、要靠更新才會變的信任名單。
瀏覽器廠商在事件公開前就已經透過自家的機制封鎖這些憑證，一般人用瀏覽器上網幾乎不受影響。事件說明頁 也提到，主流瀏覽器會要求憑證必須公開登記，而這些中繼憑證沒有登記紀錄，所以用這些瀏覽器的人不可能被這種方式騙到。
Java 不一樣。很多 Java 程式在背景運作，例如企業系統去呼叫金流、物流、政府或合作夥伴的 API，這些連線不經過瀏覽器，靠的是 Java 自己的信任名單。名單沒更新，Java 就還會相信那 8 個可以被仿造的印章。
瀏覽器 | Java 程式 | |
|---|---|---|
用誰的信任名單 | 瀏覽器自己的，可以遠端快速封鎖 | Java 自帶的，或作業系統的 |
這次有沒有風險 | 幾乎沒有，10 月 17 到 20 日已封鎖 | 名單沒更新就有風險 |
要做什麼 | 瀏覽器保持最新版 | 更新 Java，或更新作業系統的憑證 |
同樣的情況也發生在其他程式語言與工具。事件說明頁列出了 Node.js、Python、Go 等多種環境的修補版本，部分作業系統內建的工具也要另外處理。Java 只是其中拿到漏洞編號、最受關注的一個。
攻擊要怎麼成立？真實風險有多大
一句話：攻擊者要先站到「連線中間」，才用得上偽造的憑證。這不是發一個請求就能打進你主機的漏洞，但它影響的是資料的機密與完整，嚴重度一樣很高。
攻擊者需要 | 例子 | 對企業的意義 |
|---|---|---|
能攔截你的網路連線 | 公共 Wi-Fi、被入侵的路由器、被竄改的網域解析 | 系統放在雲端機房，被攔截的難度較高；員工筆電、分公司網路相對容易 |
你的程式還信任被破解的憑證 | Java 或其他程式的信任名單沒更新 | 更新完就不成立 |
你的程式會連到外部服務 | 呼叫金流、簡訊、物流、合作夥伴的 API | 連線內容可能被讀取或竄改，例如交易資料、帳號密碼 |
所以風險高低要看情境。放在雲端、只在機房內部連線的系統，被攔截的機會相對小；在員工電腦上跑的 Java 工具、在外部網路環境連線的設備，風險就高一些。不管哪一種，更新的成本都很低，沒有理由拖。
Cloudflare 在 說明 裡特別提醒一件事：更新之後如果某些連線出現憑證錯誤，不要用「關掉憑證驗證」來解決。關掉驗證等於把門鎖拆掉，所有假網站都能通過。正確做法是找出是哪個服務用了被撤銷的憑證，請對方換新。
企業該怎麼處理：照你的 Java 安裝方式選路
一句話：先確認用哪一種 Java、用哪一份信任名單，再決定更新什麼。
你的情況 | 要做的事 | 要注意的地方 |
|---|---|---|
自家開發的 Java 系統 | 請工程師更新 Java，或更新作業系統的憑證 | 容器部署的系統要確認映像檔真的換到新版 |
買來的軟體，裡面內建 Java | 問軟體廠商有沒有發布更新 | 很多 ERP、報表工具、中介軟體都內建 Java |
員工電腦上的 Java 工具 | 請 IT 統一更新 | 這類環境最容易被攔截連線 |
不確定有沒有用 Java | 請工程師盤點一次 | 順便盤點 Node.js、Python 等環境，這次也有影響 |
我們當天也盤點了自家與代管的系統，確認沒有用到 Java 執行環境。這類「公告出來先盤點」的習慣，跟我們處理 PHP2Shell 漏洞 時的做法一樣：先知道自己有什麼，才知道要修什麼。
怎麼知道公司的系統有沒有用到 Java
一句話：Java 常常藏在你看不到的地方。很多公司以為自己沒用 Java，其實是買來的軟體、伺服器上的工具裡內建了一份。下面這張表列出最常見的幾種情況，可以拿去問負責的人或廠商。
常見的地方 | 為什麼會有 Java | 怎麼確認 |
|---|---|---|
企業資源規劃、進銷存、人資系統 | 不少企業系統是用 Java 開發的，特別是大型或有歷史的套裝軟體 | 問系統廠商「系統用什麼語言開發、用哪一版 Java」 |
報表與商業分析工具 | 很多報表引擎與排程工具內建 Java 執行環境 | 看軟體的安裝資料夾或問廠商 |
搜尋、訊息佇列等中介軟體 | 常見的搜尋引擎、訊息佇列服務本身就是 Java 寫的 | 請工程師列出伺服器上跑的服務 |
內部自行開發的系統 | Java 是企業後端常見的開發語言 | 問開發團隊或看系統的技術文件 |
員工電腦上的工具 | 有些報稅、銀行、政府相關工具需要安裝 Java | 請 IT 盤點員工電腦安裝的軟體 |
盤點的時候，不只要知道「有沒有 Java」，還要知道「是哪一版、誰負責更新」。買來的軟體通常要等廠商出更新，自行開發的系統則是自己的工程師要處理。最怕的是兩邊都以為對方會處理，結果誰都沒動。
如果盤點下來發現有好幾套系統、版本各不相同，這也是一個訊號：系統的元件清單平常就該有人維護。下次有類似的公告出來，就能在一小時內回答「我們有沒有受影響」，而不是花好幾天一台一台翻。
這次事件給企業的三個提醒
提醒 | 為什麼 | 怎麼做 |
|---|---|---|
信任名單也要更新 | 大家都記得更新軟體，很少人想到憑證信任名單也會過期、也會出事 | 作業系統、程式語言環境定期更新，不只更新應用程式 |
內建在軟體裡的元件最容易被忘記 | 買來的系統內建 Java，你可能根本不知道 | 採購時要求廠商列出主要元件，並承諾資安更新的時程 |
不要為了方便關掉安全機制 | 憑證錯誤的時候，關掉驗證最快，但等於拆掉門鎖 | 建立「憑證錯誤怎麼處理」的標準流程 |
如果你的系統是外包開發的，資安更新的責任歸屬最好寫進維護合約，可以參考 維護合約範本。系統上線後的維運成本怎麼抓，客製化系統上線後的隱性成本 有整理。Java 在企業系統的定位，以及跟其他語言怎麼選，可以看 客製化系統程式語言選型。想定期檢查系統的資安狀況，弱點掃描、滲透測試、壓力測試差在哪 說明了三種檢測的差別。網站層的防護，可以搭配 WAF 是什麼 一起看。平台層的資安事件怎麼應對，則可以參考 Railway 資安事件拆解。
看到這裡，如果你也在想「我們的系統裡到底有沒有 Java、要不要更新」，我們很樂意 聽你聊聊現在的系統狀況，一起看看哪些該先處理。
ℹ️我們怎麼看
這次事件最值得注意的地方，是問題出在「信任」本身。大家花很多力氣修自己的程式漏洞，卻很少想到負責驗證身分的憑證機構也會出錯。我們的判斷是，未來幾年憑證的有效期會越來越短、撤銷會越來越頻繁，企業系統必須能「自動跟上信任名單的變化」，靠人工記得更新會越來越跟不上。給老闆的判斷工具：問負責系統的人「我們的系統多久更新一次作業系統與執行環境？上次是什麼時候？」答得出來，就有人在顧。平台資安事件的處理順序，也可以參考 Railway 資安事件拆解。
ℹ️我們做過這件事
我們累積了 40+ 企業客製案落地，系統交付後的執行環境更新、憑證管理與資安修補，是維運的日常。這次 Java 與 PHP 接連發布重大漏洞，我們都是公告當天就完成盤點。看到這裡，如果你也在想「我們的系統有沒有受影響」，我們很樂意 聽你聊聊現在的實際情況，一起看看從哪一塊開始最划算。
QCVE-2026-91403 是什麼？
CVE-2026-91403 是 2026 年 10 月 21 日公布的 Java 漏洞，嚴重度 9.1 分。原因是憑證機構 eMudhra 的 8 張中繼憑證私鑰可以被任何人算出，攻擊者能拿來偽造任何網站的憑證。Java 自帶的信任名單包含這些憑證，所以要更新 Java 或作業系統的憑證，才不會被假網站騙過。
Q這個漏洞會讓駭客直接入侵我的伺服器嗎？
不太會。它的風險在於你的 Java 程式連到外部服務時，可能被冒充的假網站攔截或竄改資料。攻擊者要先能攔截你的網路連線，再用偽造的憑證冒充目標網站。影響的是資料的機密與完整，所以嚴重度仍然很高，應該盡快更新。
Q哪些 Java 版本受影響？
OpenJDK 公告列出的受影響版本是 27.0.1、25.0.5、21.0.13、17.0.21、11.0.33、8u512 以及更早的版本。獨立安裝的 Java 要更新到 10 月 21 日之後發布的版本；用作業系統套件安裝的 Java，通常更新作業系統的憑證就夠了。
Q一般人用瀏覽器上網會受影響嗎？
幾乎不會。Firefox、Chrome、Apple、Microsoft 在 10 月 17 日到 20 日之間就已經封鎖這些憑證，而且主流瀏覽器要求憑證必須公開登記，這些中繼憑證沒有登記紀錄。保持瀏覽器與作業系統在最新版即可。
Q更新後連線出現憑證錯誤怎麼辦？
不要用關掉憑證驗證的方式解決，那等於讓所有假網站都能通過。正確做法是找出是哪個外部服務用了被撤銷的憑證，請對方更換憑證；如果是自家服務，就重新申請一張新的憑證。
Q除了 Java，還有哪些環境要注意？
這次被破解的憑證影響所有內建自己信任名單的環境。事件說明頁列出了 Node.js、Python、Go、Rust 等多種環境的修補版本，部分作業系統內建的工具也要另外處理。建議請工程師一併盤點系統用到的執行環境。
AUTHOR
恆遠數位編輯團隊
留言(0)
尚無留言，成為第一個留言的人吧！