凜喵的小窩
返回文章列表

這幾天為什麼到處都在修漏洞？看懂 2026 年 10 月的資安更新潮

2026-10-22

分享這篇文章

這幾天打開科技新聞，很容易產生一種感覺：怎麼每個軟體都出問題了？PHP 和 Node.js 發布安全更新，Java、Go、Rust 的工具也在處理憑證問題，瀏覽器和各種套件的公告又接連出現。光是看完標題，就已經有些疲憊。

不過，這些公告並不全是新發現的漏洞，也不全都來自同一場事故。把它們分開看，會比較容易判斷哪些需要立刻處理，哪些只要持續追蹤。

這篇以 2026 年 10 月 22 日能查到的資訊為準，先說明事件脈絡，再整理一般使用者與網站管理者可以採取的做法。版本與修補狀態仍可能變動，實際更新時請再對照官方公告。

先把這波新聞分成三類

第一類是 eMudhra 憑證事故引起的連鎖更新。同一批中繼憑證失去可信度，瀏覽器、作業系統、程式語言與開發工具必須各自處理。看起來有很多份公告，背後卻可能是同一個原因。

第二類是 不同專案各自發現的漏洞。例如 PHP 的遠端程式碼執行問題，以及 Node.js 的 Brotli 解碼與 TLS 驗證問題。它們需要分別評估，不能因為發布日期接近，就視為同一條攻擊鏈。

第三類是 原本就有的版本發布與修補週期。瀏覽器、微軟與 Oracle 都有自己的更新時程；專案也可能在版本發布時一次公開多份安全公告。此外，這次檢查依賴時翻出的部分問題，其實早在七月、八月或九月就已公布。

因此，公告集中出現，並不代表所有軟體正在遭受同一場攻擊。要判斷自己的風險，還是得回到軟體版本、使用方式與攻擊條件。

CVE 編號能告訴我們什麼？

CVE 是公開資安漏洞的識別編號，例如 CVE-2026-114514。它讓不同廠商、研究者和管理者能確認彼此談的是同一個問題。

有了 CVE 編號，不表示漏洞已經被大規模利用；同樣地，沒有看到攻擊新聞，也不能認為它沒有風險。公告中的受影響版本、觸發條件、修補方式，以及是否已有實際利用紀錄，都比單看編號更有用。

CVSS 分數則是在描述漏洞的技術嚴重程度，不能直接當成自己環境的風險排名。需要管理員權限才能觸發的漏洞，和任何人都能透過公開網站觸發的漏洞，處理優先順序可能很不一樣。

廣告 · Advertisement
支持本站

eMudhra 憑證事故：為什麼這麼多工具都得更新？

問題出在 HTTPS 的信任鏈

當你開啟 HTTPS 網站，瀏覽器除了建立加密連線，也要驗證對方是否有資格代表那個網域。這通常依賴一條憑證鏈：網站憑證由中繼憑證簽發，再一路連到系統或應用程式信任的根憑證。

這次事件涉及 eMudhra 的八張中繼憑證。根據 Mozilla 的事件紀錄，相關私鑰因金鑰產生問題而能被推導出來。這代表攻擊者可能利用它們簽發偽造憑證。

如果用戶端仍信任這些憑證，而且攻擊者能攔截或導向使用者的連線，就可能冒充網站、讀取或修改傳輸內容。這是嚴重的身分驗證問題，但不表示每個使用這些工具的人都已經遭到攻擊。

瀏覽器已有應對，仍應保持更新

Mozilla 的說明指出，Firefox 在 10 月 17 日收到通報後，透過 OneCRL 發送封鎖資訊；10 月 20 日發布的 Firefox 158.0.1，則進一步照顧可能因自訂設定而未收到更新的使用者。

這類機制能縮短風險持續的時間，但保護是否生效仍與瀏覽器版本、設定及更新狀態有關。不能只因為廠商已經處理，就認為所有裝置都自動安全了。

系統、容器和應用程式可能使用不同的憑證庫

比較容易漏掉的是瀏覽器以外的軟體。程式可能使用作業系統的憑證庫，也可能附帶自己的清單；容器裡的憑證庫又和主機分開。不同用戶端取得撤銷或封鎖資訊的方式，也不一定相同。

因此，只更新作業系統，未必能一併修好所有應用程式；只拉取新的容器映像，也要確認映像是否真的包含事件發生後的修補。

幾個例子可以看出這次更新為什麼分散在不同地方：

  • Go：crypto/x509 加入對已失去信任的中繼憑證的拒絕清單，相關修補為 Go 1.26.10、1.27.3，見 GO-2026-6809。
  • Rust 工具鏈：rustls-webpki 的修補涉及憑證路徑驗證；rustup 1.29.2也更新了相關依賴。
  • Node.js：10 月 21 日的安全版本同時處理了 eMudhra 事件與其他漏洞，更新範圍不限於 CA 清單。
  • Python 與其他工具：使用 certifi 或自行附帶 CA bundle 的程式，還要檢查那份憑證資料是否已更新。

curl 也要分開看：更新 curl 程式本身，和更新它使用的憑證庫，是兩件需要確認的事。 10 月 14 日發布的 curl 8.23.0 早於這次事故的通報時間，不能單憑這個版本號，就判定憑證問題已經處理完成。

若更新後遇到憑證錯誤，先確認裝置時間、軟體版本、憑證庫與網站端設定，不要直接關閉憑證驗證。憑證警告可能是在正常阻擋不可信任的連線，不應為了讓畫面恢復正常就略過它。

廣告 · Advertisement
支持本站

PHP 與 Node.js：需要另外處理的執行環境漏洞

PHP：所有提供網頁請求的部署都應檢查

PHP 在 10 月 21 日發布安全更新，修補兩個可能讓未經驗證的攻擊者執行遠端程式碼的問題：

  • CVE-2026-109618：記憶體不足時的錯誤處理，可能讓尚未完整初始化的內部請求資料進入清理流程，造成記憶體損毀。
  • CVE-2026-109619：請求使用過的內部狀態可能在記憶體釋放後殘留，並被後續請求再次使用。

修補版本是 8.5.12、8.4.27、8.3.36、8.2.35。PHP 官方公告涵蓋 PHP-FPM、Apache mod_php、php-cgi、FrankenPHP、LiteSpeed 等提供網頁請求的部署；其中 mod_php 的風險被特別強調，已有在應用程式碼執行前觸發攻擊的展示。

如果你管理 WordPress 或其他 PHP 網站，要確認的是伺服器實際使用的 PHP 版本，不能只更新網站程式或外掛。仍使用停止支援版本的人，也應向發行版或維護廠商確認回溯修補，或安排升級。官方提供部分舊版的最小原始碼修補，不代表那些版本重新獲得完整維護。

Node.js：不只憑證問題，也有解壓縮與驗證漏洞

Node.js 同日發布的安全版本為 22.23.4、24.22.1、26.12.1。官方公告包含 Brotli 解碼器越界寫入問題 CVE-2026-111497，可能導致遠端程式碼執行，另外也有 TLS 主機名稱驗證、DNS 名稱處理等修正。

是否能從某個網站觸發這些漏洞，仍取決於應用程式有沒有走到相關功能。不過，對管理者而言，既然支援中的版本已提供安全更新，就應盡快安排驗證與部署，而不是等到確認自己被攻擊才處理。

尤其要注意：更新專案的 npm 套件，不會自動更新 Node.js 執行檔。開發電腦、建置環境、正式伺服器和容器，可能各自使用不同版本，都需要分別確認。

同期還有哪些更新值得留意？

除了這次憑證事故與執行環境漏洞，其他專案也有自己的更新。下面列的是幾個值得對照使用情境的例子，不是完整漏洞清單。

瀏覽器、curl 與圖片處理工具

Chrome 在 10 月的版本更新中處理多項安全問題；Firefox 也針對憑證事故發布更新。一般使用者應確認瀏覽器已完成更新，並依提示重新啟動，不能只看到「已下載」就當作更新完成。

curl 的安全公告則列出 10 月 14 日公開的多項問題，包括 HTTP/2 上傳時的記憶體使用錯誤，以及特定情境下的認證資訊洩漏或驗證繞過。curl 既是指令列工具，也常以 libcurl 的形式被其他軟體使用，因此要留意作業系統與應用程式廠商提供的更新。

Pillow 13.0.0於 10 月 16 日發布。相關安全公告涉及 TIFF、JPEG 處理及 Ghostscript 呼叫等問題。如果網站會接收使用者上傳的圖片，或有自動轉檔服務，就應檢查實際安裝版本與處理流程。

開發工具與網站相依套件

Nuxt 在 10 月公布的問題，包括大小寫不同的路徑可能略過伺服器端路由規則，以及 Server Islands 未正確套用 useHeadSafe 過濾，相關修補版為 4.6.2。

檢查這些公告時，也容易順便查到更早的問題。例如 Vue SSR 的動態屬性名稱處理、Nuxt MDC 的網址過濾，以及 postcss-selector-parser 的資源耗盡問題，分別早在八月、七月及九月就已公布，不應只因為這次一起被整理，就寫成同一天新爆出的漏洞。

Storybook、Markdown 解析器、虛擬環境工具或 MCP SDK 也各有不同的使用條件。開發工具雖然未必會部署到正式網站，仍可能在本機處理不可信任的網頁、專案或輸入，不能一概忽略。

對開發者來說，最有用的做法是先列出自己實際安裝的版本，再逐項核對受影響範圍。套件出現在依賴樹裡，和外部攻擊者能觸發有問題的功能，必須分開判斷。

例行更新與伺服器產品

微軟的月度更新、Oracle 的季度更新，以及瀏覽器的版本發布，本來就可能一次包含多個安全修正。例行發布不代表風險比較低，只是不能把每一份公告都解讀成新的獨立事故。

如果你有使用 GitLab、Traefik、Roundcube、Plex、VPN 閘道器或其他對外服務，還要另外追蹤該產品的公告。涉及實際利用的漏洞，可以搭配 CISA 已知遭利用漏洞清單判斷處理優先順序；沒有出現在清單上，也不代表可以不更新。

廣告 · Advertisement
支持本站

一般使用者可以先做什麼？

不需要先讀懂所有漏洞編號，先把自己能控制的更新做好：

  1. 更新瀏覽器、作業系統與常用 App。 完成安裝後，依提示重新啟動。不同 App 可能附帶自己的執行環境或憑證庫，不能只更新其中一項。
  2. 檢查 NAS、路由器與自架服務。 如果家裡有跑 Plex、網站或其他可從外部連線的服務，也要查看管理介面與官方更新通知。
  3. 遇到憑證警告先查原因。 不要用略過警告、停用 HTTPS 驗證或改裝來源不明的憑證來解決。
  4. 從可信任的管道更新。 資安新聞容易被拿來包裝釣魚訊息；收到要求「立刻安裝修補工具」的連結，應自行開啟軟體或官方網站確認。

如果想判斷某一則新聞和自己有多大關係，可以先問三個問題：

  • 我有使用這個產品或相關服務嗎？ 不只是自己手動安裝的軟體，也包括裝置與 App 內附的元件。
  • 攻擊者需要哪些條件？ 對外開放的服務通常更需要優先處理；內網或本機工具仍可能透過惡意檔案、網頁或其他已遭入侵的裝置受到攻擊。
  • 修補是否已經在實際使用的環境生效？ 下載更新、修改版本設定和真正執行修補後的程式，是不同階段。

網站管理者還要多確認幾件事

這次處理網站更新時，我最在意的是把「看到公告」到「確認修補生效」之間的步驟補完整。

首先，版本應以鎖定檔、套件清單和執行中的程式為準。容器標籤叫做 latest，不表示既有容器會自動更新；主機換了憑證庫，也不表示容器和 Python 套件附帶的那份資料已經跟著更換。

接著要看漏洞的觸發條件。依賴清單裡出現某個套件，值得追查，但不能直接推論網站已遭入侵。反過來說，即使目前找不到明確的外部觸發路徑，也不應把它當成永遠不用修補的理由。

部署前應保留設定與資料備份，確認更新失敗時如何回復，並檢查新版是否需要資料庫遷移。更新後則要驗證登入、下載、付款回呼等重要流程，也要確認管理通道和外部入口仍能正常使用。建置成功或容器顯示「執行中」，都只是其中一部分。

沒有官方修補的項目，要另外追蹤。例如截至本文整理時，braces 的 CVE-2026-93687 與 node-forge 的 CVE-2026-85393 仍未在相關公告中列出修補版。這些項目需要評估可達性、替代方案或暫時措施，不能算進「全部處理完成」。

最後，日誌檢查與入侵判斷也要說清楚範圍。沒有找到可確認的入侵跡象，不等於已證明沒有遭到入侵。 如果只做了線上初查和部分日誌抽樣，就應保留這個限制。

我自己的網站做了哪些調整？

主站使用 Nuxt。這次我重新核對框架與相依套件的公告、更新相關依賴，也重新檢查了網站的維護模式。

一般維護頁的用途，是告訴訪客網站暫時不能使用，同時保留必要的管理與服務流程。但面對需要全面停止流量的資安事件，這樣的設計可能不夠：API、付款回呼或預先產生的靜態頁面，仍可能透過例外路徑被存取。

所以我把兩種需求分開處理：一般維護模式保留原本需要的例外；部署層的緊急封鎖則在載入應用程式前拒絕請求，涵蓋頁面、API、靜態資源與後台。實際保護範圍仍取決於部署與入口設定，獨立的上傳服務或其他子站需要另外處理。

樹莓派上的服務則先停止網站入口，再做入侵跡象初查、保留備份，並更新系統與容器。。

截至本文整理時，後端更新與部分驗證已完成，但管理連線在 Tailscale 更新後中斷，最後的重開機與 BunkerWeb 重新上線驗證尚未完成。這也提醒我，更新流程要涵蓋管理通道的恢復與回復方案，不能只確認套件安裝成功。

參考資料與後續追蹤

以下保留主要的官方說明與公告入口，方便對照版本及後續進展。部分公告早於這次事件，列在這裡是因為檢查時一併涉及，不代表它們都在同一週首次公開。

憑證事故

執行環境與工具

網站相依套件與待追蹤項目

面對密集的資安公告，不必把每個漏洞編號都記下來，但也別因為數量太多就全部略過。先確認自己正在使用什麼、哪些項目需要優先處理，再把更新、驗證與後續追蹤做完，會比只看新聞標題更有幫助。

拜託斗內!!!

喜歡我做的東西的話，拜託贊助一下OAO

去贊助
廣告
支持本站