摘要： eMudhra 八張中繼憑證的私鑰弱到任何人都能從公開憑證即時還原，Cloudflare 於 2026 年 10 月 30 日發表後續報告，公布網路上的實際濫用證據與修補進度。對開發者來說，重點是：偽造憑證在漏洞公開後一小時內就出現，而訪客端仍有大量瀏覽器和機器人尚未修補。
金鑰只有「4」，而且人人可重現
這次事件的本質和過往 CA 洩漏不同。Cloudflare 在 10 月 19 日得知，eMudhra 本該選擇一個 115 位數的質數作為保護網路的「密碼鎖」，結果選了數字 4；其餘七把金鑰分別是 56、66、115、155、156、230 和 237。過去 DigiNotar、TÜRKTRUST 等事件中，金鑰外洩範圍多少受到限制；這次任何人都能獨立從公開憑證還原簽章金鑰，替任意網域簽發憑證，只要客戶端未強制憑證透明化就會接受。
eMudhra 宣布退出公開 CA 業務，並聲稱是金鑰產生腳本的錯誤，但尚未公開該腳本。Cloudflare 也觀察到一個耐人尋味的細節：他們曾用一把疑似正確產生的金鑰簽署憑證撤銷清單（CRL），之後又改回用弱金鑰簽署——為什麼這沒有觸發警報，稽核與交叉簽署者的角色仍待釐清。
網路上已經有人動手
Cloudflare 在 Pingora 代理（負責絕大多數對外連線）加入記錄，10 月 21 日部署完成，用來捕捉以弱金鑰簽發憑證進行的 TLS 握手。一週內記錄到約 22,000 次嘗試：三分之二是測試站點的抓取，其餘大多是來源伺服器自己設定了弱中繼憑證。
真正值得注意的是約 160 次握手：憑證的 SAN 列出了與請求 SNI 無關的其他組織網域，包括消費性 IoT 裝置相關網域。這些偽造憑證是金鑰洩漏後才製作的，有效期超過兩年，比任何公開 CA 允許的都長。其中一張的時間戳是 10 月 20 日 18:19 UTC——Mozilla bug 報告公開後不到一小時。不過 Cloudflare 判斷這些看起來更像伺服器預設憑證而非攔截企圖，且目前沒有看到弱金鑰被用來攔截其連線的證據，也不能排除精準鎖定式攻擊。
五千萬次探測：修補比你想像的慢
為了間接測量訪客端狀況，Cloudflare 在部分挑戰頁面加上兩條探測連線，一條使用 eMudhra 簽發的憑證、一條作為對照組，一週累積約 5,000 萬次探測。結論並不樂觀：
- 最新版現代瀏覽器大致已修補，但機器人和舊瀏覽器沒有。
- Android WebView 等嵌入式瀏覽器落後，仍有 30–40% 接受該憑證鏈。
- 大型網路中，超過一半的探測仍接受這條被污染的憑證鏈，週末出現修補後趨勢轉平。
- 10 月 29 日偵測到大量自稱 Chrome 150–154 on macOS 的機器人流量，這會讓修補曲線「看似」上升，實際上只是流量分類的變化。Linux 上同版本的 Chrome 是例外，接受率持續下降。
要注意的是，挑戰頁流量本來就偏向未驗證的機器人，數據有偏誤；但正如 Cloudflare 所說，機器人也是需要安全更新的軟體——如果它們能代表整體軟體更新習慣，情況相當不妙。
開發者現在該做的事
行動清單很短：修補。Dennis Jackson 維護的眾包網站有各平台的具體步驟，macOS 開發者尤其要跟進，因為系統信任鏈的處理方式特別容易被忽略。使用 Cloudflare WARP 或 Tunnel 等產品的客戶，需依照其前一篇指引檢查自己的設定。我在先前那篇中繼憑證金鑰外洩的 builder 指南裡整理過依賴樹的判斷邏輯，可以搭配閱讀。
長期來看，Cloudflare 這篇報告真正的主張是：信任儲存庫不該是一份靜態的根 CA 清單，而要能快速接收撤銷與憑證透明化資訊——他們對 upki 這類專案的投入正說明了這一點。在漏洞揭露速度愈來愈快的環境下，「信任一次、終身有效」的模型已經撐不住了。確認你的 CI、容器映像和內部工具的信任鏈更新機制，是這週值得排進優先序的一件事。