私鑰是一個「4」：eMudhra 出包，Flutter 週末加班推 3.47.8

先把背景補上。2026 年 10 月下旬的週末，Flutter 官方緊急發布了 3.47.8 與 Dart 3.13.7 兩個安全版本，時間點就落在掘金作者「戀貓de小郭」10 月 26 日發文的前後幾天。這次更新要處理的問題源頭，其實不在 Flutter 自己身上，而是印度憑證機構 eMudhra 的中間 CA 憑證出現密鑰外流。

外流的原因荒謬到讓人想再讀一遍：eMudhra 有 8 個中間 CA 的私鑰，居然是個位數的單一位元組整數。其中一個就是一個「4」。

正常的 P-384 橢圓曲線私鑰，應該是接近 384 位元的隨機整數，理論上的可能組合是 2 的 384 次方等級。當私鑰只剩一個「4」，任何人都能在瞬間猜出來，等於這家公司的中間 CA 誰都可以偽造。依照戀貓de小郭的整理，這組弱私鑰掛在全球信任鏈上跑了一年半之久，而肇因據稱是發布時員工看錯了內容。

一家做「數位信任」的公司，先輸給了一個 4

eMudhra 的本業是數位信任服務，賣的正是憑證與身分保證。當它的中間 CA 私鑰形同公開，攻擊者理論上可以利用網路路徑，為任意域名簽出有效的 TLS/HTTPS 憑證。也就是說，受害者瀏覽器上的那個鎖頭，可能是假的。

事件曝光後，瀏覽器與作業系統陣營都發布了緊急的中間憑證黑名單，把受影響的 eMudhra 中間 CA 擋在門外。故事到這裡，看似已經收尾。

但 Flutter 的處境比較尷尬。在 Android、Windows 和 Linux 上，dart:io 走的是內建的 BoringSSL 引擎來驗證 TLS 憑證鏈，它並不讀作業系統層級的中間憑證黑名單。換句話說，桌面系統和瀏覽器都已經補了防線，用 Flutter 開發的 App 卻還站在原地。

這正是 3.47.8 存在的理由：更新 BoringSSL，讓 TLS 驗證期間直接阻擋已外流的 eMudhra 中間憑證。

順手補上的一條未來防線

這次更新還附帶了一項改動。在 Android 14 以上，dart:io 現在會從可更新的 Conscrypt APEX 模組載入系統根憑證，確保未來 Google Play 系統更新推送的根憑證存放區撤銷，能自動生效。

這條改動的意義在於：下次再發生類似的憑證撤銷事件，Flutter App 不用再等框架發版，作業系統端的更新就能覆蓋到。這次的急診，某種程度上也是在補過去架構上的單一依賴。

戀貓de小郭在文末補了一句頗有社羣味道的但書：如果你的 App 本來就直接忽略憑證驗證，那這次更新對你來說也無所謂了。這句話半開玩笑，卻也是開發者圈裡最現實的提醒。

為什麼這種消息總是在週末燒起來

安全更新挑在週末緊急發布，對開發者來說並不陌生。憑證信任鏈的問題一旦被公開掃描工具盯上，修補窗口就以小時計，框架方往往得搶在細節擴散前把版本推出去。這次 Flutter 選擇直接升級 BoringSSL 而非等待各平臺各自處理，也是因為前述的黑名單機制，本來就繞過了 Flutter 的內建驗證路徑。

從社羣反應看，這類「弱到離譜的私鑰」事件格外有傳播力。一個「4」比任何技術說明都好懂，也難怪掘金上的文章短短兩分鐘讀完，卻能讓開發者羣組一整天都在轉。對照我們先前整理過的AI 助手工作階段遭劫持事件，這一年來被討論的資安議題，共通點都是信任鏈上某一環先鬆了，而且鬆得毫無戲劇性，就是有人看錯了一個欄位。

如果你手上有使用 dart:io 進行網路請求的 Flutter 專案，這次更新值得排進本週的待辦。至於已經忽略憑證驗證的那批 App，問題就不在這次更新能解決的範圍了。