CVE-2026-111943 技術解析：eMudhra CA 私鑰可還原漏洞的攻擊面與修補建議
Gertech 耘鼎科技 資安情報｜2026-10-24｜標籤：PKI、TLS、憑證授權機構（CA）、供應鏈信任、Java、Go
事件仍在發展中，本文資訊整理至 2026 年 10 月 24 日。
重點摘要
- 印度憑證機構 eMudhra 旗下 8 張中繼 CA 憑證，其 P-384 私鑰數值全部小於 256，研究人員僅需逐一嘗試 256 種可能，即可從公開憑證直接還原私鑰。有研究人員表示，在筆電上不到 1 秒就能全數還原，其中一把私鑰的值甚至只有 4。
- 中繼 CA 私鑰一旦被掌握，攻擊者理論上可簽發瀏覽器與作業系統信任的任意網域憑證，搭配中間人攻擊（MITM）即可冒充網站或攔截加密流量。
- Google、Mozilla、Apple、Microsoft 已在 10 月 17 日至 20 日間陸續封鎖，目前沒有證據顯示遭到實際濫用。
- 真正的風險在於不檢查撤銷資訊的用戶端：舊版 Java、以 Go 編譯的應用程式、內嵌裝置、容器映像與自帶 CA 清單的軟體，必須透過更新才能獲得防護。
事件經過
10 月 17 日，一名以「Wayne」為名的研究人員向 Apple、Google、Microsoft、Mozilla 與 eMudhra 通報，並以 8 把私鑰對同一段訊息簽章，證明自己持有金鑰。Mozilla 事件報告指出，這 8 張憑證使用 2025 年 4 月產生的 P-384 私鑰。研究人員 Flüpke 隨後在 GitHub 公開了這批私鑰，BleepingComputer 已獨立驗證其與被撤銷的憑證相符。
換句話說，這批私鑰目前已是公開資訊，任何人皆可取得。
技術解析：為什麼 8 個位元就足以動搖信任
ECDSA 的安全性建立在「由公鑰反推私鑰」在計算上不可行。公鑰是私鑰 d 與曲線基點 G 的純量乘積（Q = d·G），P-384 的私鑰空間約為 2³⁸⁴，正常情況下無法暴力破解。
本案的問題不在演算法，而在金鑰產生流程：這 8 把私鑰的 d 都落在 0 到 255 之間，有效熵只有約 8 個位元。攻擊者只需對每個 d 計算 d·G，再比對憑證中的公鑰，最多 256 次運算即可命中。據報導，8 把私鑰的值分別為 4、56、66、115、155、156、230 與 237。
eMudhra 向 Mozilla 表示，金鑰產生儀式使用的腳本有錯誤，另外產生了一組較弱的金鑰，因為名稱相近，被人為誤用來產生憑證簽署請求（CSR），且流程中多個步驟都出現人為疏失。公司同時表示，其基礎設施並未遭入侵，根 CA 私鑰也未受影響。這類失誤指向的是儀式控管與交叉覆核（maker/checker）的缺口，而非密碼學強度不足。
受影響範圍
| 類別 | 憑證 |
|---|---|
| TLS 伺服器憑證用（6 張） | EM DV TLS CA、EM OV TLS CA、EM EV TLS CA 的 G3B（eMudhra BV，荷蘭）與 G3C（eMudhra Inc，美國）版本 |
| 程式碼簽章用（2 張） | EM OV CS CA 的 G3B 與 G3C 版本 |
我們核對公開的憑證檔後確認，這 8 張中繼憑證的簽發者為 Comodo／Sectigo 的 AAA Certificate Services 根憑證（交叉簽署版本），有效期間自 2025 年 5 月 14 日至 2028 年 12 月 31 日。這也是為何 Debian、Homebrew 等下游發行方除了移除 emSign 根憑證，連 AAA Certificate Services 也一併移除，並造成部分合法憑證鏈暫時失效。
eMudhra 表示，8 張憑證中只有 1 張曾部署到正式環境，且均未簽發終端實體憑證。Chrome 則指出，封鎖前並沒有鏈結到這 6 張 TLS 中繼憑證的 TLS 憑證出現在憑證透明度（CT）紀錄中，因此強制檢查 CT 的瀏覽器預設不會信任偽造憑證。但由於不是所有用戶端都強制檢查 CT，且金鑰自 2025 年起就處於可被還原的狀態，無法完全排除過去曾被濫用的可能。
各方因應
| 對象 | 因應措施 |
|---|---|
| Google Chrome | 10/17 透過 CRLSet 封鎖 6 張 TLS 中繼憑證；並決定將 emSign ECC Root CA - G3 自 Chrome Root Store 移除，預計 10/27 起向使用該憑證庫的裝置推出更新 |
| Mozilla Firefox | 10/17 透過 OneCRL 封鎖；釋出 Firefox 158.0.1、ESR 115.43.1 與 153.5.1，NSS 3.131.1 移除該根憑證 |
| Apple、Microsoft | 分別於 10/19、10/20 跟進封鎖 |
| Go | 釋出 1.27.3 與 1.26.10（CVE-2026-111943），標準函式庫驗證憑證鏈時會過濾這些中繼憑證；應用程式須以新版重新編譯才生效，Go 1.25 以前版本已終止支援 |
| Python certifi、Rust webpki-roots、Homebrew | 自 CA 憑證套件移除相關根憑證 |
| Linux 發行版 | Ubuntu、Debian、Fedora、Arch、Gentoo、Alpine 已有更新套件；FreeBSD、Node.js、Bun 在資安人報導時仍待修補 |
為什麼說「撤銷」不等於「安全」
瀏覽器可透過 CRLSet、OneCRL 等機制自動下載撤銷資訊，因此能在數小時內完成封鎖。然而 Mozilla 密碼學工程師 Dennis Jackson 指出，許多其他用戶端並不使用撤銷資訊，必須透過軟體更新，才能不再信任這些中繼憑證。Cloudflare 的分析也提醒，企業應用程式可能採用不同的 TLS 憑證驗證機制，即使 Chrome 與 Firefox 已封鎖，其他軟體仍可能繼續信任。
實務上，下列環境最需要優先盤點：
- 信任清單編譯進執行檔、不檢查撤銷與 CT 的應用程式（例如以 Go、Rust 編譯的服務）
- 長期未更新的容器基底映像與
ca-certificates套件 - 舊版 Java 執行環境與自帶信任庫的軟體
- 內嵌裝置、IoT 設備與無法自動更新的老舊系統
- 使用 emSign ECC Root CA - G3 憑證鏈的對外網站（根憑證被移除後可能連線失敗）
可能的攻擊情境：不只是「理論風險」
多數報導停留在「攻擊者理論上可偽造憑證」這個概括講法。實際上，依 8 張憑證的用途拆開來看，至少存在三條不同的濫用路徑，風險等級與持續時間也不同。
情境一：偽造任意網域的 TLS 憑證，發動中間人攻擊
8 張憑證中有 6 張是 TLS 伺服器憑證用的中繼 CA。由於私鑰可在本機以不到 1 秒的時間還原，攻擊者可以簽發任何網域（包含 google.com 這類熱門網域）的憑證，只要受害端的信任庫仍接受這批中繼憑證所掛的根（emSign ECC Root CA - G3 或交叉簽署的 AAA Certificate Services），該偽造憑證在鏈驗證上即判定為合法。這讓攻擊者得以在公用 Wi-Fi、受駭的網路設備、企業內網等場景發動中間人攻擊，攔截或竄改 HTTPS 流量，而使用者端不會跳出憑證警告。
目前主流瀏覽器已撤銷這批憑證，CT 紀錄中也沒有發現惡意簽發的痕跡，一般使用者只要保持瀏覽器更新，風險不高。
自簽合法google憑證 示意圖
情境二：偽簽惡意程式，冒充知名廠商簽署
另外 2 張是程式碼簽章（code signing）用的中繼 CA，這是風險等級更高、也是目前中文資安媒體較少著墨的一塊。只要掌握私鑰，攻擊者理論上可以簽發以任意組織名稱呈現的程式碼簽章憑證，使惡意程式在系統屬性的「數位簽章」欄位顯示為受信任廠商。這會連帶衝擊多個依賴「簽署者身分」的防護機制：
- Windows SmartScreen／防毒信譽評分：未知發布者通常會被攔截或顯示警示，但已簽章且簽署者為知名廠商的執行檔，往往會被放行或降低警示等級
- EDR／防毒產品的白名單邏輯：部分產品把「已簽章且來自大廠」納入降低風險分數的判斷依據
- 企業應用程式白名單（AppLocker、WDAC 等）：若信任條件設定為「依簽署者放行」，偽造的簽章可能直接繞過限制
需要說明的是，程式碼簽章信任通常還涉及時間戳記服務（RFC 3161）與憑證簽發時的身分驗證流程，單純擁有中繼 CA 私鑰未必能無痛複製出所有平台都承認的「正式發布者」簽章；但對於只做基本簽章驗證、不交叉比對發布者細節的環境，風險依然存在。企業應優先確認防護機制是否真的依賴「憑證鏈是否受信任」而非「發布者名稱是否眼熟」來做判斷。
可能會被拿來簽mimikatz等惡意程式 示意圖
情境三：網通設備與內嵌裝置可能「通殺」式暴露，且修補週期極長
瀏覽器能在數小時內透過 CRLSet、OneCRL 等機制自動封鎖，但多數網通設備（路由器、防火牆、NAS、印表機等）與內嵌裝置的信任庫是編譯進韌體的根憑證清單，通常不檢查撤銷清單（CRL/OCSP），也不檢查憑證透明度（CT），甚至部分設備對憑證鏈的驗證本就寬鬆。只要設備信任庫裡仍含有 emSign ECC Root CA - G3 或 AAA Certificate Services，該設備就會持續信任用這批外洩私鑰簽出的任意憑證，直到廠商釋出韌體更新為止。
考量這類設備的韌體更新週期普遍是半年到數年，甚至有不少已停產、不再收到更新，實務上可以合理預期：這批金鑰造成的風險會以「年」為單位持續存在於部分網通與嵌入式環境中，而不是像瀏覽器端那樣幾天內就處理完畢。這也是企業在盤點時最容易遺漏、但影響期最長的一塊。
與 Oracle Java 緊急公告的關聯
Oracle 在 10 月 20 日發布 2026 年第四季度關鍵修補更新（處理 1,209 個漏洞）後，10 月 21 日再度緊急發布 CVE-2026-91403 公告，CVSS 3.1 評分 9.1，元件為 Java 安全通訊端擴充套件（JSSE），受影響產品包含 Java SE 8u511、11.0.33、17.0.21、21.0.13、25.0.5、27.0.1 與 GraalVM。Oracle 公告並未說明成因，也未直接列出修補版本，需登入技術支援網站查閱。
據報導，同日發布的 OpenJDK 公告將此漏洞與 eMudhra 中繼憑證事件連結。但這項關聯目前主要來自媒體引述，Oracle 本身並未證實，建議企業以官方公告為準，不要僅憑傳聞判斷是否需要處置。
耘鼎科技 建議行動
以下建議為 Gertech 耘鼎科技依事件資訊整理，供企業資安與維運團隊參考：
短期（立即）
- 更新作業系統、瀏覽器與 Java 執行環境，並確認 CA 信任清單為最新版本。
- Go 應用程式升級至 1.27.3 或 1.26.10 以上，重新編譯並重新部署。
- 重建容器映像，確認
ca-certificates套件已更新；注意 Node.js、Bun、FreeBSD 的後續修補進度。 - 檢查對外網站的憑證鏈，若使用 emSign ECC Root CA - G3，請改用其他受信任 CA 簽發的憑證。
- 使用事件追蹤網站提供的測試網址，確認環境中的用戶端是否仍信任這些中繼憑證。套用移除根憑證的作法前，請先在測試環境驗證，避免影響既有服務。
中期（強化）
- 建立「信任庫資產清冊」：盤點哪些系統、語言執行環境與應用程式自帶 CA 清單，並納入弱點管理與更新流程，特別納入網通設備、NAS、印表機等內嵌裝置的韌體信任庫，這類設備不會自動撤銷，暴露期最長。
- 評估關鍵服務是否能以憑證釘選（certificate pinning）、強制 CT 檢查或內部 PKI 縮小信任範圍。
- 檢視 EDR、防毒產品與應用程式白名單（AppLocker、WDAC 等）的信任邏輯，確認是否僅依「簽署者名稱」放行，而非驗證完整憑證鏈與信譽評分，避免偽簽程式碼繞過防護。
- 將 CA 事件納入資安情資與應變演練，確保在根憑證被移除時，能快速辨識受影響的憑證鏈與服務。
- 對內部自建 PKI，檢視金鑰產生儀式、亂數來源與雙人覆核機制，並使用經驗證的硬體安全模組（HSM）與作業系統提供的安全亂數來源。
檢討
這起事件再次說明，信任鏈的強度取決於最弱的一環。演算法沒有被破解，卻因金鑰產生流程失誤，讓 HTTPS 信任體系的一個節點在一年半的時間裡形同虛設。更值得注意的是，瀏覽器能在數小時內止血，但整個生態系的清理工作，仍然需要靠每個維運團隊逐一更新、重建與重新編譯，這段落差才是企業最大的暴露面。
*本文由 Gertech 耘鼎科技 整理分享。如需憑證與信任庫盤點、PKI 治理或資安事件應變諮詢，歡迎聯繫我們。
參考資料
- iThome：印度數位憑證業者eMudhra中繼CA私密金鑰可被還原，瀏覽器緊急封鎖相關憑證
- iThome：甲骨文緊急修補Java 重大漏洞，被傳與eMudhra中介憑證外洩有關
- 資安人：印度憑證機構「eMudhra」八把中繼 CA 金鑰外洩，Chrome、Firefox 與 Apple、Microsoft 緊急封鎖相關憑證
- SecTools.tw：eMudhra 中介憑證私鑰外洩：8 張 CA 憑證遭四大瀏覽器封鎖
- BleepingComputer：Mozilla, Google, Apple block compromised eMudhra CA certificates
- Scott Helme：Eight Bits of Trust; eMudhra's CA keys cracked in milliseconds
- Mozilla 事件追蹤：Bugzilla 2083449
- 事件追蹤與檢測網站：emudhra.we-have-a-problem.com