Key Takeaways
- PHP 資安團隊已於 2026 年 10 月 21 日 13:37 UTC（台灣時間 21:37）釋出修補程式，修補 CVE-2026-109618 與 CVE-2026-109619 兩個重大漏洞。兩者 CVSS v4.0 評分均為 9.2，可能導致未經身分驗證的遠端程式碼執行（RCE）。
- 漏洞成因分別是記憶體不足（OOM）處理過程中的記憶體損壞，以及請求之間殘留的過期全域狀態所引發的釋放後使用（Use-After-Free）。對外提供網頁服務的 PHP 環境（包括 Apache mod_php 與 PHP-FPM）都受影響，但攻擊所需的條件會因設定而有所不同。
- 公開攻擊程式碼在官方修補釋出前就已出現，並回報已成功對 Apache mod_php 達成遠端程式碼執行與 ASLR 繞過。這讓尚未修補的系統風險大增，不過目前尚無經獨立證實的實際攻擊成功案例。
- 修補版本為 PHP 8.2.35、8.3.36、8.4.27 與 8.5.12。已結束支援的舊版本也可能受影響；使用廠商維護 PHP 套件的企業，請確認是否已提供回溯修補（Backport）。
- 目前沒有完整的替代方案（Workaround）。企業應立即優先修補對外開放的 PHP 環境，確認更新後的執行環境確實生效，並調查可能已遭入侵的系統。暫時性的設定調整可以降低曝險，但無法取代修補。
- TrendAI™ 客戶已具備防護。TrendAI Vision One™ TippingPoint™ Digital Vaccine 過濾器與入侵防禦規則可為有漏洞的系統提供屏障防護，TrendAI Vision One™ Network Detection and Response（NDR）則可偵測 PHP 遠端程式碼執行的攻擊流量。
事件經過：PHP 漏洞是怎麼外洩的？
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 環境達成遠端程式碼執行的可能路徑。企業現在應優先修補，並調查可能已遭入侵的系統。
漏洞詳情與最新狀態
| 項目 | 說明 |
|---|---|
| 修補釋出時間 | 2026 年 10 月 21 日，PHP 官方釋出安全修補版本。 |
| 嚴重程度 | 重大（Critical），兩項漏洞的 CVSS v4.0 評分均為 9.2。 |
| 漏洞類型 | CVE-2026-109618 為記憶體不足（OOM）處理異常造成的記憶體損毀；CVE-2026-109619 為全域狀態殘留造成的釋放後使用（Use-After-Free）。兩者均可能導致未經驗證的遠端程式碼執行（RCE）。 |
| 受影響版本 | PHP 8.2.35、8.3.36、8.4.27 及 8.5.12 之前的對應分支版本均受影響。 PHP 7.4、8.0、8.1 等已停止官方支援的舊版分支亦可能受影響。PHP 官方已提供相關原始碼回移修補，但實際修補狀態仍須依作業系統或套件供應商公告確認。 |
| 受影響設定 | 漏洞影響環境包括 Apache mod_php、PHP-FPM、CGI、FrankenPHP 及 LiteSpeed。其中 Apache mod_php 與 PHP-FPM 已確認存在遠端程式碼執行攻擊路徑，實際影響取決於部署設定。CLI 環境若處理不可信輸入，亦可能受影響。 |
| 實際攻擊狀況 | 已有資安研究機構通報觀測到攻擊嘗試，截至 2026 年 10 月 22 日，尚無公開證實的成功入侵案例。 |
| 公開概念驗證（PoC） | 已有公開攻擊程式碼及研究人員成功重現 RCE 的報告，Apache mod_php 環境已確認可遭利用；公開程式碼的有效性仍須個別驗證。 |
| 替代方案 | 無完整替代方案。可依官方指引調整記憶體限制、停用 session.upload_progress.enabled 及限制外部存取，以降低部分風險，但仍須優先套用安全修補。 |
為什麼這個 PHP 漏洞很重要？
全球有相當高比例的網站是用 PHP 架設的，而其中很多都不在資安團隊第一時間會檢查的地方。PHP 往往隱身在內容管理系統（CMS）與電商平台底層、容器映像檔內、主機代管的管理後台，以及各種設備與網路裝置的網頁管理介面中。這些 PHP 環境很多是由主機代管商、作業系統廠商或設備廠商在維護，而不是依賴它們的企業自己。
由於漏洞出在 PHP 本身，它的層級比應用程式更底層。更新 WordPress、Magento 或自行開發的應用程式，對這次的漏洞完全沒有作用。修補必須套用在 PHP 執行環境上，而且要由負責該執行環境的人來做。
這次攻擊程式碼搶在 PHP 於 10 月 21 日釋出修補前就已曝光，研究人員也回報已成功對有漏洞的 Apache mod_php 設定達成遠端程式碼執行與 ASLR 繞過，企業幾乎沒有緩衝時間。攻擊者現在可以直接研究、改寫這些程式碼，不必再透過逆向分析修補程式來找漏洞。雖然目前尚無經獨立證實的實際攻擊成功案例，但現成的攻擊程式碼已大幅提高未修補系統遭到大規模攻擊的風險。企業應立即優先部署修補。
企業現在該怎麼做：PHP 漏洞應變 7 步驟
- 盤點所有由您負責的 PHP 執行環境。 不要只看網頁伺服器，容器映像檔、CI 建置映像檔、無伺服器（serverless）函式、開發與測試主機，以及內建 PHP 的第三方產品都要納入。記錄確切版本與安裝來源：作業系統套件、官方原始碼編譯、容器映像檔、主機代管商或設備廠商。這決定了修補會由誰提供、什麼時候提供。
- 依曝險程度排定優先順序。 先處理對外開放的 PHP 應用程式，尤其是接受檔案上傳、具有管理後台，或處理付款與客戶資料的系統。其次是內部使用者網路可以連到的內部系統。
- 盤點無法取得修補的系統。PHP 8.1 及更舊版本已不在官方支援範圍。部分 Linux 發行版與商業供應商會將資安修補回溯到舊版本，請先查閱廠商公告，不要只憑版本號就認定系統尚未修補。若確定沒有修補，應限制存取、隔離該系統，或升級到仍在支援期內的版本。
- 確認誰負責替您修補。 向主機代管商、委外管理服務商（MSP）與設備廠商確認更新的釋出時程。作業系統套件可能比官方版本慢一步。即使版本號與官方不同，也要確認已安裝的套件是否包含這次的資安修補。
- 做好部署與驗證更新的準備。 預先核准緊急變更、備妥測試與建置流程，並用更新後的 PHP 套件或基礎映像檔重新建置容器映像檔。確認修補後的執行環境真的已經部署，並重啟受影響的服務或替換執行中的容器，確保載入的是新版程式碼。
- 在修補到位前先降低曝險。 將不必要的 PHP 應用程式從網際網路下線，並透過 VPN 或白名單限制管理介面的存取。套用現有的 WAF 與入侵防禦規則，但不要假設通用規則就能擋下攻擊。停用 session.upload_progress 並未經確認能同時防護兩個漏洞，絕對不能拿來取代修補。
- 修補之後，持續監控是否已遭入侵。 立即開始監控對外開放的系統，更新後也要持續。留意異常的 HTTP 請求、PHP 工作處理程序（worker）無故啟動 shell 或下載工具、被篡改的應用程式檔案、Web Shell，以及可疑的對外連線。這些都是一般性的入侵指標，不是針對這兩個漏洞的專屬偵測。優先調查在補上修補前曾持續對外開放的系統。
面對 PHP 漏洞，TrendAI™ 能幫上什麼忙？
- 決定從哪裡先著手。 TrendAI Vision One™ 資安曝險管理（Cyber Risk Exposure Management，CREM）提供企業裝置、帳號、應用程式、雲端資產與對外資產的攻擊面全貌。它會為每項資產標註重要性等級，資安團隊也可自行調高關鍵系統的等級，藉此取得一份已排好優先順序的曝險系統清單，知道該先修補、先調查哪些。
- 尋找入侵跡象。 TrendAI Vision One™ Agentic SIEM 與 XDR 中的 XDR Data Explorer 可搜尋端點的程序活動，比對「先修補，再追查入侵跡象」一節描述的行為，例如 PHP 工作處理程序啟動 shell 或下載工具。
- 交給專家處理。 對於人力不足、無法自行執行的團隊，TrendAI Vision One™ Services – Managed Detection and Response（MDR）由 TrendAI 分析師透過同一套 Vision One 監控數據，提供 24 小時全年無休的偵測、調查與回應。想確認自己是否已被鎖定的企業，可申請 TrendAI 入侵評估（compromise assessment）；若研判已遭入侵，請聯繫 TrendAI 資安事故應變團隊。TrendAI 客戶如有疑問可聯繫專屬業務代表；其他需要協助的企業，請透過 TrendAI 聯絡頁面 。
常見問題（FAQ）
CVE-2026-109618 與 CVE-2026-109619 是什麼漏洞？
兩者都是 PHP 執行環境本身的重大漏洞，CVSS v4.0 評分均為 9.2。CVE-2026-109618 是記憶體不足處理時的記憶體毀損，CVE-2026-109619 是請求之間過期全域狀態引發的釋放後使用。兩者皆可能導致未經驗證的遠端程式碼執行。
哪些 PHP 版本受影響？要升級到哪個版本？
8.2.35、8.3.36、8.4.27 與 8.5.12 之前的對應分支均受影響，請升級至這些版本或更新。PHP 7.4、8.0、8.1 只有原始碼層級的回移修補，請確認作業系統或主機廠商是否提供對應套件。
我只更新 WordPress 或 Laravel 就安全了嗎？
不夠。漏洞出在 PHP 執行環境，不是應用程式本身。必須更新 PHP，並重啟 PHP-FPM、Apache 或替換容器，讓新版本真正載入。
沒辦法馬上修補，有應急的做法嗎？
沒有完整的替代方案。PHP 建議可先設定 memory_limit=-1 並搭配資源控管（針對 CVE-2026-109618），以及停用 session.upload_progress（針對 CVE-2026-109619），但這些做法無法封鎖所有攻擊路徑，仍要盡快更新。
已經有實際攻擊了嗎？
公開攻擊程式碼已在 GitHub 上流通，也有早期攻擊嘗試的回報，但目前尚無經獨立證實的實際攻擊成功案例。
怎麼知道自己是否已經被入侵？
檢查是否有異常的 HTTP 請求、PHP 工作處理程序無故啟動 shell 或下載工具、應用程式檔案被篡改、出現 Web Shell，以及可疑的對外連線。優先調查在補上修補前曾持續對外開放的系統。