兩大 PHP重大高風險漏洞 CVE-2026-109618／109619 修補前遭外洩：企業與 IT 團隊當前應對指南

2026 年 10 月 20 日 15:20 UTC，一篇 Hacker News 貼文揭露了兩個可能導致遠端程式碼執行的 PHP 重大漏洞細節。貼文雖已被移除，但截圖已在 X 與 Mastodon 上流傳。資安研究機構 watchTowr 隨後證實這兩個漏洞，並確認編號為 CVE-2026-109618 與 CVE-2026-109619。原定的協同揭露日期為 10 月 22 日。
同日稍晚，PHP 資安團隊發布通知，警告漏洞存在，但未公開技術細節與受影響版本。

10 月 21 日 13:37 UTC，PHP 釋出這兩個漏洞的資安更新，兩者 CVSS v4.0 評分均為 9.2，在多種 PHP 部署設定下都可能導致未經身份驗證的遠端程式碼執行。從 8.2 到 8.5 共四個受支援的 PHP 分支均已提供修補。
公開攻擊程式碼也在官方釋出前就已出現，展示了對有漏洞的 Apache mod_php 環境達成遠端程式碼執行的可能路徑。企業現在應優先修補，並調查可能已遭入侵的系統。

全球有相當高比例的網站是用 PHP 架設的，而其中很多都不在資安團隊第一時間會檢查的地方。PHP 往往隱身在內容管理系統（CMS）與電商平台底層、容器映像檔內、主機代管的管理後台，以及各種設備與網路裝置的網頁管理介面中。這些 PHP 環境很多是由主機代管商、作業系統廠商或設備廠商在維護，而不是依賴它們的企業自己。
由於漏洞出在 PHP 本身，它的層級比應用程式更底層。更新 WordPress、Magento 或自行開發的應用程式，對這次的漏洞完全沒有作用。修補必須套用在 PHP 執行環境上，而且要由負責該執行環境的人來做。

這次攻擊程式碼搶在 PHP 於 10 月 21 日釋出修補前就已曝光，研究人員也回報已成功對有漏洞的 Apache mod_php 設定達成遠端程式碼執行與 ASLR 繞過，企業幾乎沒有緩衝時間。攻擊者現在可以直接研究、改寫這些程式碼，不必再透過逆向分析修補程式來找漏洞。雖然目前尚無經獨立證實的實際攻擊成功案例，但現成的攻擊程式碼已大幅提高未修補系統遭到大規模攻擊的風險。企業應立即優先部署修補。

1.盤點所有由您負責的 PHP 執行環境。

不要只看網頁伺服器，容器映像檔、CI 建置映像檔、無伺服器（serverless）函式、開發與測試主機，以及內建 PHP 的第三方產品都要納入。記錄確切版本與安裝來源：作業系統套件、官方原始碼編譯、容器映像檔、主機代管商或設備廠商。這決定了修補會由誰提供、什麼時候提供。

2.依曝險程度排定優先順序。

先處理對外開放的 PHP 應用程式，尤其是接受檔案上傳、具有管理後台，或處理付款與客戶資料的系統。其次是內部使用者網路可以連到的內部系統。

3.盤點無法取得修補的系統。

PHP 8.1 及更舊版本已不在官方支援範圍。部分 Linux 發行版與商業供應商會將資安修補回溯到舊版本，請先查閱廠商公告，不要只憑版本號就認定系統尚未修補。若確定沒有修補，應限制存取、隔離該系統，或升級到仍在支援期內的版本。

4.確認誰負責替您修補。

向主機代管商、委外管理服務商（MSP）與設備廠商確認更新的釋出時程。作業系統套件可能比官方版本慢一步。即使版本號與官方不同，也要確認已安裝的套件是否包含這次的資安修補。

5.做好部署與驗證更新的準備。

預先核准緊急變更、備妥測試與建置流程，並用更新後的 PHP 套件或基礎映像檔重新建置容器映像檔。確認修補後的執行環境真的已經部署，並重啟受影響的服務或替換執行中的容器，確保載入的是新版程式碼。

6.在修補到位前先降低曝險。

將不必要的 PHP 應用程式從網際網路下線，並透過 VPN 或白名單限制管理介面的存取。套用現有的 WAF 與入侵防禦規則，但不要假設通用規則就能擋下攻擊。停用 session.upload_progress 並未經確認能同時防護兩個漏洞，絕對不能拿來取代修補。

7.修補之後，持續監控是否已遭入侵。

立即開始監控對外開放的系統，更新後也要持續。留意異常的 HTTP 請求、PHP 工作處理程序（worker）無故啟動 shell 或下載工具、被篡改的應用程式檔案、Web Shell，以及可疑的對外連線。這些都是一般性的入侵指標，不是針對這兩個漏洞的專屬偵測。優先調查在補上修補前曾持續對外開放的系統。