cloudflared 要更新嗎？eMudhra 憑證外洩後，Cloudflare Tunnel 升級步驟與防範做法

只要你公司有用 Cloudflare Tunnel 把內部系統開到外面（ERP 後台、NAS、接 webhook 的服務都算），每一台跑 cloudflared 的機器都要升級到 2026.10.2 以上；在 macOS 上沒用 Homebrew 安裝的，要升到 2026.10.3 以上。原因是憑證機構 eMudhra 有 8 張中繼憑證的私鑰被破解，舊版 cloudflared 還會相信這些憑證，攻擊者有機會拿偽造的憑證冒充連線對象。

2026 年 10 月 27 日，我們也收到 Cloudflare 寄來的通知信，信裡寫得很直接：你的帳號底下至少有一條 Tunnel 在跑，cloudflared 依賴的第三方憑證已經確定外洩，請盡快把每一個 cloudflared 升級。我們回頭一查，公司內部一台 Mac mini 上的 cloudflared 還停在 2026.3.0，當天就升完了。這篇把整件事拆成老闆和 IT 都看得懂的版本：發生什麼事、誰會被影響、怎麼更新、以後怎麼不要再被追著跑。

cloudflared 要更新嗎？一張表看懂這次事件

要，而且要盡快。下面這張表是整件事的重點，趕時間的話看完這張就可以去更新了。

Cloudflare Tunnel 可以想像成「從公司裡面往外挖的一條專用通道」：公司不用在防火牆上開洞，外面的人經過 Cloudflare 再沿著這條通道進來。cloudflared 就是裝在公司那一端、負責挖通道的那支程式。想先弄懂 Tunnel 在 Cloudflare 整套產品裡的位置，可以看我們寫過的 Cloudflare Zero Trust 是什麼。

eMudhra 憑證外洩發生什麼事：8 張中繼憑證的私鑰被破解

一句話：負責替網站「蓋章認證身分」的其中一家機構，有 8 顆印章被人複製了。

網路上的 HTTPS 連線，靠的是憑證鏈在證明「我真的是我」。最上層是根憑證，往下是中繼憑證，再往下才是每個網站自己的憑證。中繼憑證就像總公司授權給分公司的印章，分公司蓋的章，大家一樣認。現在 eMudhra 有 8 顆分公司印章的私鑰外流，拿到的人可以替任何網域蓋出一張假憑證，而還在信任這些中繼憑證的軟體會照單全收。憑證鏈怎麼運作，在 SSL 憑證是什麼 那篇有用印章比喻完整講過。

時間線是這樣的：Cloudflare 在官方部落格的事件說明寫到，他們在 2026 年 10 月 19 日約 17:00 UTC（台灣時間 10 月 20 日凌晨 1 點左右）得知這 8 張中繼憑證的私鑰已經外洩，並在 10 月 20 日公開說明。文中提到這些金鑰本身強度不足，但沒有說明是怎麼被破解的。影響範圍也講得很清楚：攻擊者可以替任何網域做出偽造憑證，用來冒充伺服器，攔截或竄改流量。

同一件事也波及其他軟體。Java 因為自帶信任清單，同樣要更新，我們在 Java 漏洞 CVE-2026-91403 白話拆解 那篇整理過 Java 的處理方式。這篇專心講 cloudflared。

為什麼 cloudflared 也要更新：瀏覽器一鍵處理，自帶信任清單的軟體不行

因為 cloudflared 要靠憑證驗證來確認連線對象，它在更新之前會繼續相信那 8 張外洩的中繼憑證。

Cloudflare 在事件說明裡點出差別：瀏覽器廠商可以「切一個開關」就讓全世界的瀏覽器不再信任這些憑證；可是很多系統是把信任清單包在程式或映像檔裡，要換清單就得重新發版、重新部署。Cloudflare 優先處理的，就是那些用公開憑證去驗證遠端端點的服務，例如代理到來源主機的連線、應用程式去呼叫外部 API。cloudflared 正好屬於這一類，所以通知信說它「依賴第三方憑證的完整性」，必須更新才能停止信任這些憑證。

最容易被忽略的是容器。映像檔一旦建好，裡面的信任清單就凍結在建置那天，主機怎麼更新都碰不到它。如果對容器的概念還不熟，可以先看 Docker 容器是什麼。

哪些 Cloudflare 產品受影響：版本與處理方式對照表

除了 Tunnel，Cloudflare 自家幾個用戶端程式也都發了新版。下面整理自 Cloudflare 的事件說明，對照你公司有用到的項目逐一確認。

有用 Gateway、而且用戶端保持最新的公司，Cloudflare 表示已經自動受到保護。員工電腦上的 WARP 交給 MDM 或自動更新就好，真正要 IT 親自處理的，多半是機房或辦公室裡那幾台跑 cloudflared 的主機。

cloudflared 怎麼更新：依安裝方式選指令

先查版本，再照安裝方式升級，最後重新啟動服務。三步驟每台機器都要跑一次。

第一步，在每台主機上確認目前版本：

cloudflared --version

看到的版本低於 2026.10.2，就照下表處理。指令整理自 Cloudflare 官方的 cloudflared 更新文件。

Docker 的部分建議把版本寫死，不要用 latest。寫死版本的好處是你清楚知道每台跑的是哪一版，下次出事時查起來快：

docker pull cloudflare/cloudflared:2026.10.4
# docker compose 的 image 欄位改成 cloudflare/cloudflared:2026.10.4 之後
docker compose up -d

Linux 上用 systemd 跑的服務，升完記得確認服務有起來：

sudo systemctl restart cloudflared.service
sudo systemctl status cloudflared.service --no-pager
cloudflared --version

還有一件事一定要記住：如果升級後某些服務出現憑證錯誤，請不要用「關掉憑證驗證」來解決。Cloudflare 在說明裡特別強調這一點。出錯代表那條連線真的用到了不再被信任的憑證，要做的是換掉對方的憑證或更新信任清單，關掉驗證等於把大門打開。

我們自己的更新紀錄：一台 Mac mini，中斷約 15 秒

10 月 27 日收到 Cloudflare 的信之後，我們先盤點自己有哪些機器在跑 cloudflared，結果是公司內部一台 Mac mini。它是用 Homebrew 安裝、以 launchd 服務常駐，啟動參數裡帶了 --no-autoupdate，也就是關掉了 cloudflared 內建的自動更新。版本停在 2026.3.0，比這次要求的版本舊了半年多。

實際做的事只有兩步：

brew upgrade cloudflared            # 2026.3.0 → 2026.10.4
launchctl kickstart -k gui/$(id -u)/com.cloudflare.cloudflared
cloudflared --version

服務重新啟動後，Tunnel 大約 3 秒內就重新註冊完成，4 條連線分別接到 Cloudflare 的高雄（khh01）與台北（tpe01）節點。從開始升級到服務恢復，整體中斷大約 15 秒。

這次學到的一課在 --no-autoupdate。用服務方式安裝 cloudflared 時，很常會看到這個參數，因為大家不希望程式在半夜自己換版本。這個選擇本身合理，但它有個代價：關掉自動更新之後，更新這件事就要有人負責。我們的 Mac mini 安安穩穩跑了半年，沒人想到要看版本，直到 Cloudflare 寄信來。

更新完怎麼確認：連線、版本與相依套件三件事

確認三件事：每台 cloudflared 都升了、Tunnel 連線恢復正常、同一台主機上其他依賴憑證的程式也更新了。

• 到 Cloudflare Zero Trust 控制台的 Tunnel 頁面，看每個連接器（connector）回報的版本，確認沒有漏網的舊版。實際跑過的人都知道，最常漏的是「當初測試裝的那台」。
• 用你的應用程式實際走一次對外連線來驗證，例如觸發一次 webhook、登入一次後台。Cloudflare 建議依應用程式實際的 TLS 路徑來驗證，光看版本號不夠。
• 順著相依關係往下查：主機的 ca-certificates 套件、Python 的 certifi、Node.js 執行環境、容器的基底映像，這些都各自帶著信任清單。Cloudflare 也提醒要檢查整個相依樹。

要確認是否已經被入侵，請以官方說法為準：Cloudflare 目前只說在自家服務上沒看到實際被利用的跡象，這句話的範圍是 Cloudflare 的服務，不代表你自己的每一條連線都沒事。如果你的系統在這段期間有異常的憑證錯誤或流量，值得翻一下紀錄。

怎麼避免下次又被追著跑：把更新變成例行公事

重點在於讓「該更新了」這件事有人看見、有流程接手，不靠廠商寄信提醒。

Cloudflare 在說明最後也提到長期解法：信任清單要能像 Chrome 的 CRLSets 那樣快速更新，並整合撤銷與憑證透明度（CT）的資訊，他們也在推動 upki 這類專案。這是產業層級的事，中小企業能做的，就是先把自己這端的更新流程補起來。

用 Tunnel 把內部系統開到外面，維運上要補哪些制度

如果你公司的 ERP、後台或 NAS 是靠 Tunnel 對外，這次事件提醒的其實是維運責任歸屬：系統上線那天有人裝好 Tunnel，之後誰負責更新？

我們的看法很直接：Tunnel 是很好的工具，它讓中小企業不用開防火牆埠、不用架 VPN 就能安全地把系統開出去，這個方向我們在 Zero Trust 是什麼 和 零信任怎麼導入 都推薦過。但「裝好就不用管」是誤會。cloudflared 是一支會持續發新版的程式，跟作業系統、資料庫一樣，需要排進更新清單。

對老闆來說，可以用三個問題檢查自己公司：

• 公司有幾台機器在跑 cloudflared，有人說得出來嗎？
• 這些機器上次更新是什麼時候，誰負責？
• 委外廠商的維護合約裡，有沒有寫到「第三方元件的資安更新」由誰做、多久內做完？

第三題最常出問題。很多維護合約只寫「系統故障排除」，資安更新落在灰色地帶。簽約前可以參考 軟體維護合約的計價模式與條款 和 IT 維護合約範本，上線後第一年要注意的事則整理在 系統上線第一年的維護指南。同樣是「上游出事、下游要跟著更新」的情境，TanStack npm 供應鏈攻擊的應變 那篇也可以一起看；伺服器本身的防護則可參考 伺服器防火牆是什麼。

如果你公司的內部系統也是用 Tunnel 對外，但不確定有哪些機器、誰在維護，我們很樂意聽你聊聊現在的架構，一起把清冊和更新流程整理出來。這類部署與維運的盤點，本來就是我們客製化系統開發的一部分。